Яка кількість токенів за секунду вимірюється 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 бере репрезентативне навантаження RAG як орієнтир та підсумовує: 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: що це таке і що він вимірює сьогодні

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 мс на 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 с та 30 мс відповідно (близько 1600 ppm) для таких випадків, як чат, кодування або творчі інструменти.

Основні характеристики виробника та оператора

• NVIDIA знову лідирувала, цього разу з Blackwell Ultra на системі GB300 NVL72, набравши Рекорд у міркуваннях з пропускною здатністю DeepSeek‑R45 на 1 відсотків більшою, ніж у 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 результатів, що посіла перше місце. DL1a Gen380 виділявся в DLRM та Llama 12‑3.1B (сервер) серед 8-графічних систем PCIe; DL8 Gen385 відзначено кращу продуктивність графічного процесора в 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 раза порівняно з Xeon 5-го покоління за результатами п'яти бенчмарків, закріплюючи його роль у загальному логічному виведенні. Також було представлено робочі станції з 8 графічними процесорами Arc Pro B60, 192 ГБ відеопам'яті для обслуговування 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 ГБ 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 продемонструвала найкращі результати з 200-графічними процесорами HGX‑B8 (повітряно-рідинний), що були оснащені процесорами 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 на графічному процесорі та нейронному движку, перевершив цільову точність у категорії граничних значень та продемонстрував, що оцінку якості можна проводити на споживчому обладнанні.

Швидкість, яку сприймають користувачі, та практичні обмеження

Досвід користувача вимірюється не лише бенчмарками; у повсякденному житті, Відчуття плинності виникає, коли ви перевищуєте певний поріг токенів за секунду.Один користувач зазначив, що їхнє обмеження для розмови становить 4 токени за секунду, а для написання історій — близько 10 токенів за секунду; нижче цього значення взаємодія здається повільною.

Якщо ви спробуєте запустити LLM локально, то стикаєтеся з трьома реальностями. На настільному процесорі, Нормально рухатися зі швидкістю 1–2 жетони за секунду., нездійсненно для довгих відповідей. З високопродуктивним ігровим графічним процесором ви можете отримати близько 5 токенів за секунду. З NVIDIA H100, так, ми вже говоримо про 60 токенів за секунду, але це обладнання для центрів обробки даних, а не для настільних комп'ютерів.

Що відбувається у хмарі? Найпотужніші провайдери перевершують ці показники завдяки спеціалізованому обладнанню та оптимізованим стекам виводу. В середньому на ChatGPT‑119 повідомлялося про близько 4 токенів за секунду, а на Gemini — 168., тоді як популярні моделі з відкритим кодом, такі як DeepSeek, обробляють близько 21 токена за секунду. Якщо перевести це в слова, 119 токенів за секунду – це приблизно 90 слів за секунду.

Оперативний висновок: для більшості користувачів, Запуск ШІ на комп'ютері можливий, але непрактичний через повільність.Для роботи на комфортній швидкості та з мінімальними затримками керовані сервіси залишаються розумним варіантом.

Як визначити розмір кінцевої точки за TPS та чого очікувати від затримки

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

Далі узгодьте конфігурацію зі своїм шаблоном. Якщо ваше робоче навантаження нагадує посилання на Databricks (2048 входів, 256 вихідів), Виберіть діапазон токенів за секунду таким чином, щоб запит потрапляв у бажаний бюджет затримкиПам'ятайте, що дублювання виводу зазвичай коштує дорожче, ніж дублювання вводу, і що ефективна паралельність залежить від фактичного автомасштабування.

Контролюйте та коригуйте. Слідкуйте за показниками налаштований паралельний процес, черги, TTFT та TPOT, і порівняйте його з вашими SLO. Якщо у вас обмаль потужностей, розширте діапазон; якщо у вас надлишок ресурсів, зменште його та налаштуйте блоки для економії. Справжня формула масштабування допоможе вам зрозуміти, чому кінцева точка не працює належним чином, якщо вона не створила достатньо реплік.

Зрештою, майте на увазі сценарій. В інтерактивному режимі чат-бота, прагніть до TTFT 0,5 с та 30 мс на токен Це забезпечить вам преміальний користувацький досвід. У режимі сервера 2 с та 100 мс на токен є розумними рекомендаціями, а в автономному режимі він прагне максимальної пропускної здатності, зберігаючи при цьому точність, необхідну для бенчмарка.

Дивлячись на тенденції MLPerf, вектор зрозумілий: Більше контексту, більше токенів та кращі методи підвищення ефективності — дезагреговане обслуговування, FP4/FP8, структуроване обрізання, користувацькі ядра, планування кешу KV — підвищують стелю токенів другий рік поспіль, як на чіп, так і на систему.

Загальна картина, отримана за допомогою Databricks та MLPerf, є послідовною: Мислення з точки зору кількості токенів за секунду – це правильний спосіб міркувати про вартість, затримку та масштабованість у LLM.Завдяки гарному репрезентативному бенчмарку, метрикам TTFT/TPOT та добре відкаліброваному автомасштабуванню можна забезпечити швидку та стабільну реакцію без перевищення розміру інфраструктури.

Пов'язана стаття:

NVIDIA Blackwell Ultra GB300: Архітектура, пам'ять та NVLink 5