Какви са токените в секунда, измерени от MLPerf, и как се използват в LLM?

Ръководство за хардуер » еталони » Какви са токените в секунда, измерени от MLPerf, и как се използват в LLM?

Ако работите с езикови модели, сте чували термина „токени в секунда“ хиляди пъти, но рядко се обяснява подробно какво означава той в реални среди и най-вече как MLPerf го измерва. В тази статия обясняваме ясно какво представляват токените, защо метриката „токени в секунда“ е толкова важна при изводите и как платформи като Databricks и бенчмарка MLPerf я използват за оразмеряване, сравняване и мащабиране. Освен това, включваме конкретни данни от производителите и очакванията за производителност от облаците до земята..

Проблемът не е маловажен: индустрията е стандартизирала броя токени в секунда, за да оцени производителността на LLM в центрове за данни и на периферията. MLPerf, рецензираният пакет MLCommons, се превърна в еталон за сравняване на хардуер и софтуер.Успоредно с това, оператори като Databricks вече предоставят крайните точки на своите модели директно въз основа на диапазон от токени в секунда. Нека разгледаме всичко това по-подробно, с числа и случаи на употреба.

Какво е токен и защо е важен в LLM?

Езиковите модели не обработват отделни букви или думи такива, каквито са; те работят с единици, наречени токени. Един токен обикновено е дълъг около 4 знака или средно 0,75 думи.Това съотношение варира в зависимост от езика и токенизатора на модела, но служи за бърза справка: текст от 10 думи се движи около 13–14 токена.

Точното сегментиране зависи от модела: Всеки LLM използва свой собствен токенизатор и разделя думите на пълни токени или поддуми.Онлайн инструментите ви позволяват да видите например как Llama токенизира конкретна фраза. Тази променливост, която изглежда като малък детайл, влияе върху латентността и изчислителните разходи.

Когато говорим за скорост на генериране, тя обикновено се изразява в брой токени в секунда, а не в брой думи в секунда. Това хомогенизира метриката между езици, дължини на контекста и стилове на изход.и позволява точното изчисляване на разходите за извод и необходимия капацитет.

Защо измервате производителността в токени в секунда, а не в RPS?

Традиционните API услуги се фокусират върху RPS (заявки в секунда). В LLM този подход е недостатъчен: Две заявки могат да отнемат много различно време в зависимост от входните и изходните токени.Тоест, действителният полезен товар се изразява в токени, а не в „брой повиквания“.

Има два ключови източника на променливост. Първо, дължината на входния контекст: Краткият подкаст може да съдържа само няколко токена, но обобщаващият документ може да нарасне до стотици или хиляди.От друга страна, дължината на изхода: обобщаването обикновено произвежда по-малко токени; генерирането на дълга статия или описание увеличава времето, защото декодирането на изхода е най-скъпата част.

Следователно, за да се мащабира реалистично крайна точка на извод, е полезно да се мисли от гледна точка на токени. Например, Databricks предоставя на своите обслужващи крайни точки диапазон от токени в секунда и таксува почасово въз основа на мащабирането.По този начин можете да синхронизирате капацитета с действителното натоварване, без да се заблуждавате от RPS, който не разказва цялата история.

Как Databricks и MLPerf измерват токени в секунда

Databricks взема представителен набор от RAGs като отправна точка и обобщава: 2048 входни жетона и 256 изходни жетонаТой комбинира двете фази (предварително попълване и декодиране) и по подразбиране оптимизира баланса между пропускателна способност и латентност за партиди с размер от 1 заявка, симулирайки множество едновременни заявки.

С това правило числата се четат така: ако конфигурирате крайна точка на 2304 токена в секунда (2048 + 256), Заявка с тези размери отнема около секундаАко го зададете на 5600 токена в секунда, същата заявка пада до около 0,5 секунди и можете да обработвате две подобни заявки в секунда.

Когато работното ви натоварване се промени, латентността ще се промени. Генерирането на повече изходни токени е повече санкциониращо от увеличаването на входните токени.Ако правите пакетен извод, изчислете средния брой входни и изходни токени за вашия набор от данни и го сравнете с предишния бенчмарк, за да оцените времената.

Практически примери: с 1000 реда, средно 3000 входни и 500 изходни токена и осигурена пропускателна способност от 3500 токена в секунда, ще ви отнеме повече от 1000 секунди защото средните ви стойности надвишават референтните. Ако вместо това усредните 1500 входни и 100 изходни данни с 1600 токена в секунда, ще паднеш под 1000 секунди общо за тези 1000 реда.

Автоматично мащабиране при поискване и изчисление на действителното мащабиране

Обслужването на модели на Databricks включва бързо автоматично мащабиране, което Увеличаване или намаляване на ресурсите въз основа на търсенето на токени в секундаСистемата се мащабира в блокове капацитет, а допълнителният капацитет се таксува само когато се използва. При тестове с повече паралелни заявки, осигурената пропускателна способност се увеличава, докато се стабилизира на около 8000 токена в секунда, когато ресурсите са наситени, което увеличава латентността на опашките.

Ако забележите по-малко жетони в секунда, отколкото сте отбелязали, проверете две неща: Осигурена паралелност, отразяваща показателите за крайни точки и минималния размер на честотната лента конфигуриран. С тези данни, действителното мащабиране се оценява по формулата: осигурена паралелност × минимален размер на честотната лента / 4.

Конкретен пример: с максимална едновременност от 8 и минимален размер на стрипа от 850 токена в секунда, Ефективният лимит би бил 1700 токена в секунда. (8 × 850 / 4). Разбирането на това изчисление предотвратява изненади и ви помага да прецизирате настройките си спрямо вашите SLO за латентност.

MLPerf Inference: Какво е това и какво измерва днес

MLPerf, разработен от MLCommons, е отвореният и стандартизиран пакет за измерване на производителността на изкуствения интелект в центровете за данни и периферните среди, от зрението до LLM. Целта му е да сравнява платформите по справедлив и възпроизводим начин, за да повиши ефективността на екосистемата.През последните години фокусът очевидно се измести към GenAI и големите LLM.

В петото издание, Llama 2 70B беше консолидиран като водещ бенчмарк, измествайки ResNet50, и Показателите за токени в секунда са се подобрили до 3,3 пъти в най-добрия случай за една година., със средна производителност 5 пъти по-висока благодарение на хардуерни и софтуерни оптимизации. Присъствието на процесори като Intel Xeon 6 в официалните резултати също показа, че В определени сценарии има място за ефикасни универсални решения.

Версия 5.1 на MLPerf Inference направи още една крачка напред: тя включва три нови ключови показателя, разсъждения с DeepSeek-R1, преобразуване на реч в текст с Whisper Large v3 и малък LLM, базиран на Llama 3.1 8BКато цяло консорциумът отчете 27 участници, достигна етапа от 90.000 XNUMX резултата и стесни показателите за латентност в интерактивни сценарии.

Показатели и цели в новите бенчмаркове

Сравнителният тест за разсъждение с DeepSeek‑R1, MoE с 671B параметри, показва, че Тези модели произвеждат дълги вериги от разсъждения, преди да стигнат до отговора.Поддържа изходи до 20.000 3880 токена, със средно XNUMX токена на изход в набора от данни, най-големият до момента в областта на инференцията.

Правилата измерват пропускателната способност в офлайн режим и сървърен режим със строги ограничения: Време до първия токен от 2 секунди и латентност на токен от 80 ms на p99Това се стреми да балансира „мислещия“ бюджет с необходимата бързина на реакция за неговото прилагане.

Малкият LLM бенчмарк с Llama 3.1‑8B замества GPT‑J 6B като шлюз. Поддържа контексти до 128.000 XNUMX токена и оценява обобщението в CNN‑DailyMail със 778 входни токена и 73 изходни токена. Точността се валидира с ROUGE и в затворено деление се изисква да съответства на 99 процента от бенчмарк с висока точност.

В показателите за латентност се използват два индикатора: TTFT (време до първия токен) и TPOT (време на изпращане на токен). На сървъра са отбелязани 2 секунди TTFT и 100 мс TPOT. (около 480 ppm), а в новия интерактивен сценарий е свито до съответно 0,5 s и 30 ms (около 1600 ppm) за случаи като чат, кодиране или креативни инструменти.

Акценти на производителността от производителя и оператора

• NVIDIA отново поведе, този път с Blackwell Ultra на системата GB300 NVL72, отбелязвайки Рекорд в разсъжденията с 45 процента по-висока пропускателна способност DeepSeek‑R1 от GB200 NVL72, достигайки 5842 токена в секунда на графичен процесор офлайн и 2907 на сървъра, с подобрения близо 5 пъти в сравнение с непроверения Hopper.
• В новия интерактивен бенчмарк Llama 3.1 405B, NVIDIA приложи дезагрегирано сервиране с Динамо, разделяйки контекста и генерирането на различни графични процесори и прехвърляйки KV кеша през NVLink, постигайки 1,5× по-голяма пропускателна способност на графичен процесор в сравнение с традиционното обслужване на Blackwell и повече от 5× повече от системите с Hopper.
• За по-малките модели, NVIDIA съобщи Над 18.000 3.1 токена в секунда на графичен процесор на Llama 8 XNUMXB офлайн и 5667 токена в секунда на графичен процесор в Whisper, поддържайки лидерство в графичните процесори във всички сценарии (офлайн, сървърни и интерактивни).
• AMD разшири присъствието си с първата доставка на графичния процесор Instinct MI355X, който вече е в диапазона 2‑70B. Той показа мащабиране на множество възли и 2,7 пъти увеличение на токените в секунда спрямо MI325X в FP8.При отворено деление, структурирана резитба е приложена върху Llama 3.1‑405B (FP4), увеличаване на производителността с 82 процента с модел с 21 процента по-дълбоко подрязана структура и с 90 процента с 33 процента по-прецизен модел, поддържайки прецизност.
• Също така дебютираха доставките на Llama 2‑70B Interactive, Mixtral‑8×7B и Stable Diffusion XL, и представиха смесени резултати за MI300X/MI325X: При мащабиране до 4 възела, MI355X постигна 3,4 пъти по-голяма пропускателна способност от MI300X, разширяващ се до 8 възела с добра мащабируемост.
• HPE, комбинирайки ProLiant и Cray, отчете 14 резултата номер 1. DL380a Gen12 се открои в DLRM и Llama 3.1‑8B (Сървър) сред 8-GPU PCIe системи; DL385 Gen11 отбеляза по-добра производителност на графичния процесор в Whisper с H200 NVL; а Cray XD670 (8× H200) отбеляза шест първи места в RetinaNet, Llama 3.1‑8B, Mixtral и Whisper, плюс първи места с RTX Pro 6000 Blackwell SE и GH200 NVL2 резултати в DLRM.
• CoreWeave беше първият облак, който отчете резултати с GB300, предоставяйки 6005 токена в секунда на графичен процесор в DeepSeek‑R1 офлайн и демонстриране на оркестрация и мащабиране със Slurm върху Kubernetes и планиране, съобразено с топологията, за да се извлече максимума от NVLink.
• Dell достави 12 системи с ускорители AMD и NVIDIA, блестящи в LLaMA 2 70B Interactive с PowerEdge XE9680L и B200, LLaMA 3.1‑8B сървър на XE9685L+B200, SDXL на XE9685L и Whisper на XE9680L, демонстрирайки гъвкавост от изображение до глас чрез LLM.
• Intel подчерта, че остава единственият, който изпраща резултати със сървърни процесори и показа, че Xeon 6 с P-ядра се подобрява с 1,9 пъти спрямо 5-то поколение Xeon в пет бенчмарка, затвърждавайки ролята си в общоприложимите изводи. Също така бяха представени работни станции с 8 графични процесора Arc Pro B60, със 192GB VRAM за обслужване на Llama2‑70B на множество потребители, както и пакетни драйвери и рамки за опростяване на внедряването на множество графични процесори.
• Сред интеграторите и партньорите, ASUSTeK Оптимизирана латентност и пропускателна способност с квантуване, ядра и стекBroadcom демонстрира VCF виртуализация с минимални режийни разходи в сравнение с гол метал при множество натоварвания (Whisper, SDXL, Llama 3.1-405B, Llama2-70B, RGAT, RetinaNet); Cisco мащабира почти линейно с UCS C885A M8 (8× H200 SXM) и UCS C845A M8 (8× H200 NVL или L40S), поддържани от One G200 мрежи.
• KRAI, използвайки OpenAI API и реалистични разходи, сравни SGLang и vLLM с Llama3.1‑70B: 31.391 0.4.9 токена в секунда офлайн със SGLang XNUMX и 26.319 0.9.2 с vLLM 8 на един сървър с 200x H27.697; с динамично квантуване достигна 30.893 87.334 с SGLang и XNUMX XNUMX с vLLM, а на многовъзлова система мащабира до XNUMX XNUMX токена в секунда на три сървъра.
• Lambda, с 8x B200 180 GB SXM, показа подобрения в пропускателната способност до 7 процента в SDXL и 15 процента в Llama 3.1‑405B в сравнение с предишния кръг и предлага клъстери от 16 до 1536 графични процесора с управлявани Kubernetes или Slurm.
• MiTAC, със своята серия G8825Z5, блесна на LLaMA 2 70B Interactive с... 18.846,1 токена в секунда и добри резултати в Server и Mixtral; Nebius сертифицира виртуализираната си производителност почти наравно с тази на голия метал в GB200 NVL72, HGX B200 и HGX H200, с 596,11 токена в секунда на сървъра и 855,82 токена офлайн на Llama 3.1‑405B с 4 GB200 графични процесора.
• Red Hat демонстрира vLLM като поддържана среда за изпълнение на своя AI Inference Server, с Ядра CUTLASS за FP8 и FlashAttention‑3 плюс подобрен двигател vLLM v1, задвижва Llama‑3.1‑8B в H100 и L40S с отлично съотношение цена-качество.
• Supermicro постигна водещи резултати с HGX‑B200 8‑GPU (въздух и течност) с процесори Intel и AMD, подчертавайки... Llama 3.1‑8B и Llama 2‑70B на сървър/офлайн/интерактивен и Whisper; в сътрудничества показа отлично мащабиране с 32× H100‑SXM и алтернативи с MI325X.
• Vultr дебютира със Supermicro AS‑8126GS‑TNMR и 8x MI325X, сертифицирайки конкурентна производителност като облачен графичен процесор; GATEOverflow повишена възпроизводимост с MLCFlow на RTX 4090 и AMD/Intel процесори; Giga Computing достави 8U системи EPYC+MI325X и Xeon+HGX B200 с въздушно охлаждане; QCT обхвана Xeon 6 конфигурации с H200 NVL (4 графични процесора) и 8× H200 SXM5 платформи с NVLink и GPUDirect Storage, в допълнение към 8× MI325X системи.

Академичните среди също имаха своя момент. Университетът на Флорида, със своя DGX B200 SuperPOD, интегриран с HiPerGator, беше първата институция, която представи резултати от изводи Спазване на латентностите на сървъра при затворено разделяне, използване на Apptainer без Docker/Sudo и вписване в многопотребителски SLURM. В противоположния край, еднократно подаване на M1 MacBook Pro, с ONNX Runtime и CoreML на GPU и Neural Engine, надмина целевата точност в категорията на ръба и демонстрира, че изводът за качество може да бъде оценен на потребителски хардуер.

Скорост, възприемана от потребителите, и практически ограничения

Потребителското изживяване не се измерва само в бенчмаркове; в ежедневието, Усещането за флуидност идва, когато превишите определен праг от токени в секунда.Един потребител коментира, че ограничението им за разговор е 4 токена в секунда, а за писане на истории е около 10 токена в секунда; под това ниво взаимодействието се усеща бавно.

Ако се опитате да стартирате LLM локално, има три реалности. На настолен процесор, Нормално е да се движите с 1-2 жетона в секунда, не е възможно за дълги отговори. С висок клас геймърски графичен процесор можете да получите близо 5 токена в секунда. С NVIDIA H100, да, вече говорим за 60 токена в секунда, но това е хардуер за центрове за данни, а не хардуер за настолни компютри.

Какво се случва в облака? Най-мощните доставчици надминават тези цифри благодарение на специализиран хардуер и оптимизирани инферентни стекове. Средно около 119 токена в секунда са отчетени в ChatGPT‑4 и 168 в Gemini., докато популярни модели с отворен код като DeepSeek се движат около 21 токена в секунда. Ако преобразувате това в думи, 119 токена в секунда са около 90 думи в секунда.

Оперативно заключение: за повечето потребители, Стартирането на изкуствен интелект на компютъра е възможно, но непрактично поради бавността му.За работа с комфортни скорости и с малки латентности, управляваните услуги остават разумният вариант.

Как да оразмерите крайната си точка по TPS и какво да очаквате от латентността

Практически стъпки за оразмеряване. Първо, очертайте вашия случай на употреба: Среден брой входни и изходни токени, разпределение на дължината и очаквана паралелностВторо, проведете тест за натоварване с представителен набор от данни, включващ TTFT и поддържани токени в секунда на заявка.

След това подравнете конфигурацията с вашия шаблон. Ако работното ви натоварване наподобява референтното за Databricks (2048 входа, 256 изхода), Изберете диапазон от токени в секунда, така че заявката да попада в желания бюджет за латентностНе забравяйте, че дублирането на изхода обикновено струва повече от дублирането на входа и че ефективната паралелност зависи от действителното автоматично мащабиране.

Следете и коригирайте. Следете показателите осигурена паралелност, опашки, TTFT и TPOTи го сравнете с вашите SLO. Ако нямате достатъчно капацитет, разширете диапазона; ако имате излишни ресурси, намалете го и коригирайте блоковете, за да спестите. Формулата за истинско мащабиране ще ви помогне да разберете защо крайната точка не работи както е конфигурирана, ако не е създала достатъчно реплики.

И накрая, имайте предвид сценария. В интерактивен режим, подобен на чатбот, Стремете се към TTFT от 0,5 секунди и 30 милисекунди на токен. Това ще ви осигури първокласно потребителско изживяване. В сървърен режим, 2 s и 100 ms на токен са разумни насоки, а офлайн се търси максимална пропускателна способност, като същевременно се поддържа точността, изисквана от бенчмарка.

Разглеждайки тенденциите в MLPerf, векторът е ясен: Повече контекст, повече токени и по-добри техники за ефективност — дезагрегирано обслужване, FP4/FP8, структурирано подрязване, персонализирани ядра, планиране на KV кеша — увеличават тавана на токените с втора година спрямо предходната, както на чип, така и на система.

Цялостната картина, начертана от Databricks и MLPerf, е последователна: Мисленето от гледна точка на броя токени в секунда е правилният начин за разсъждение относно разходите, латентността и мащабируемостта в LLM.С добър представителен бенчмарк, TTFT/TPOT показатели и добре калибрирано автоматично мащабиране е възможно да се осигурят бързи и стабилни отговори, без да се преоразмерява инфраструктурата.

Свързана статия:

NVIDIA Blackwell Ultra GB300: Архитектура, памет и NVLink 5