Визначте корисний результат, перш ніж шукати швидкість
В інтерактивному режимі вимірюйте очікування першого токена та повної відповіді. Для офлайн-корпусу вимірюйте час, потрібний для отримання всіх очікуваних виходів. В обох випадках зафіксуйте правило приймання: точність на відомих відповідях, якість ранжування або перевірене вилучення полів. Синтаксично коректний JSON усе одно може містити хибну відповідь.
Відокремлюйте очікування в черзі, обробку та повний шлях, який спостерігає ваш клієнт, коли ваші інструменти це дозволяють. Вимірювання всередині рушія має інші межі, ніж вимірювання застосунку. Документація метрик vLLM розрізняє, зокрема, очікування, перший токен і загальну тривалість: зберігайте це розрізнення у своїх записах, який би рушій ви не обрали.
Технічні джерела: vLLM — метрики запитів і затримки
Перетворіть свої запити на критерії вибору
Підготуйте короткі, звичайні та довгі входи зі стабільними ідентифікаторами. Збережіть модель, токенізатор, шаблон розмови та параметри генерації. Рахуйте токени, які реально передаються, включно з історією та документами, доданими застосунком. Записуйте окремо запитаний батч, надіслану одночасність і запити, що фактично обробляються одночасно: це не обов'язково ті самі числа.
| Вхід для фіксації | Вимірювання та одиниця | Наслідок для вибору |
|---|---|---|
| Повний запит і ліміт виходу | Вхідні та вихідні токени на запит | Перевірити довгі випадки та відповіді, обрізані на ліміті |
| Одночасні запити та темп надходження | Активні, в черзі та завершені запити | Визначити стійке навантаження за потрібної затримки |
| Точність, квантизація та кеш | Пік пам'яті на GPU, у байтах або Gio | Відкиньте налаштування, які перевищують памʼять за очікуваного навантаження |
| Правило якості та еталонні значення | Прийнятні виходи / очікувані виходи; бізнес-метрика | Порівнюйте лише варіанти, що відповідають однаковому критерію |
| Межі вимірювання часу | Перший токен, повна відповідь або корпус: секунди | Порівнюйте тривалості з однаковими межами |
| Час до отримання файлів | Загальне вікно, у годинах або днях | Потім виберіть тариф на 3, 7 або 30 днів |
Вимірювання памʼяті з урахуванням контексту й паралелізму
Для авторегресивної моделі, яка генерує токен за токеном, KV-кеш зберігає стани уваги. Його розмір залежить від моделі та збережених токенів. Динамічний кеш може зростати під час генерації; статичний кеш резервує максимальний розмір. Деякі шари з ковзним вікном обмежують це зростання. Тож перевіряйте заплановані довжини та паралелізм із тією стратегією, яку реально використовуєте.
Квантизація ваг і квантизація кешу — це два різні вибори. Наприклад, bitsandbytes замінює деякі лінійні шари на квантизовані версії; це не описує всіх виділень памʼяті під час вашого виконання. Після зміни точності перевіряйте памʼять і якість заново, а не припускайте, що весь пік зменшується в тій самій пропорції.
З PyTorch окремо фіксуйте пік виділених тензорів і пік памʼяті, зарезервованої алоатором. Не додавайте їх. Зазначайте вимірюваний GPU та одиницю: 1 ГіБ відповідає 2³⁰ байтів. Ці лічильники не обовʼязково охоплюють усе використання пристрою. Розділ про памʼять детально пояснює їхні обмеження.
Технічні джерела: Hugging Face Transformers 5.17 — стратегії KV-кешу · Hugging Face Transformers 5.17 — квантизація bitsandbytes · PyTorch 2.14 — керування памʼяттю CUDA та лічильники
Вимірюваний тест на 300 документах
Приклад, який слід виконати з вашим дозволеним корпусом: витягніть дату, суму та категорію з 300 документів. Перегляньте очікувані значення, уточніть обробку відсутніх полів і встановіть поріг прийнятності до тесту. Кількість документів описує протокол; жоден час, бал чи пропускна здатність не передбачаються.
- Зафіксуйте 300 ідентифікаторів, ревізію моделі, промпти, обмеження токенів і правило парсингу. У підсумку зберігайте ідентифікованість довгих документів.
- Виконайте еталонний запуск з одним запитом за раз. Відокремте завантаження, прогрів і вимірювання; зберігайте прогнози та помилки для кожного документа.
- Потім збільшуйте лише один параметр: batch для групової обробки або паралелізм для рушія запитів. Зберігайте ті самі вхідні дані та критерії якості.
- Для кожного проходу фіксуйте тривалість, пік памʼяті, кількість знайдених ідентифікаторів без дублікатів і прийнятні виходи. Повторюйте вимірювання та зберігайте необроблені значення разом з їхнім розкидом.
- Якщо варіант не спрацював, зафіксуйте причину: памʼять, обрізання, формат чи якість. Зменшений batch або повторний запуск створює рішення, яке слід задокументувати, а не помилку, яку треба стерти.
Технічні джерела: IteraGPU — детальний протокол порівняння за однакової якості
Використання ресурсів IteraGPU Lab v1 у належних межах
Ноутбук та його супровідний скрипт пропонують розрахунок ваг і вимірювання на невеликій синтетичній мережі. Їхній код вимірювання було виконано на локальній RTX 5070 з PyTorch 2.11.0 на невеликій конфігурації у float32. Цей тест перевіряє цей випадок виконання; він не вимірює ні LLM, ні KV-кеш, ні GPU з каталогу на ваших запитах.
Використовуйте ноутбук, щоб зрозуміти лічильники, а потім вимірюйте своє реальне навантаження в його середовищі. Протокол якості та необроблена таблиця слугують для підготовки порівняння. Виходи розповсюдженого ноутбука та рядки результатів у CSV залишаються порожніми; процедура не встановлює жодної моделі чи драйвера. Перед запуском прочитайте передумови в README.
- Ноутбук для роботи з памʼяттю IteraGPU Lab v1
Розрахунки та невелика синтетична мережа для розуміння вимірювання памʼяті.
- Протокол якості для заповнення
Фіксовані вхідні дані, прийнятність виходів і порівняння тестів.
- Порожня необроблена таблиця
Один рядок на кожен реальний прохід, з параметрами, вимірюваннями та вердиктом.
- Передумови та обмеження IteraGPU Lab v1
Інструкції та точні межі вже виконаного локального тесту.
Перехід від вимірювань до пропозиції
Ваш аркуш вибору має об'єднувати сумісне середовище, пам'ять на карту, контекст, паралелізм, досягнуту якість і виміряні строки. Порівняйте конфігурації, що відповідають цим критеріям, а потім тарифи на 3, 7 і 30 днів за повним графіком: підготовка, обробка, оцінювання, відновлення та експорт. Калькулятор із набору бенчмарків використовує повний тариф і справді перевірені корисні корпуси.
Зберігайте цей аркуш і версії коду у своєму журналі. Ви обираєте власне програмне забезпечення та обробку; IteraGPU не перевіряє вміст ваших файлів, запитів чи обчислень. Вибір середовища під час замовлення виражає вашу потребу в підготовці: він не є доказом того, що вашу модель уже встановлено чи протестовано.
Практичні питання
Чи достатньо 24 ГБ для моєї моделі інференсу?
Обсягу 24 ГБ недостатньо, щоб відповісти без знання моделі та навантаження. Перевіряйте разом ваги, розподіл під час виконання, контекст і одночасні запити. Конфігурація має завершувати тривалі випадки із заданою якістю; сам лише розмір файлу чи оцінка ваг цього не доводить.
Яку пропускну здатність порівнювати для офлайн-корпусу?
Порівнюйте насамперед час, потрібний, щоб завершити й оцінити той самий корпус. Якщо ви публікуєте показник пропускної здатності, наводьте кількість прийнятих корисних виходів, врахований час та помилки. Показник у токенах за секунду без довжини відповіді та контролю якості не дає змоги розрізнити дві конфігурації.
Чи вимагає перевищення пам'яті зміни GPU?
Перевищення пам'яті передусім вимагає визначити налаштування та вхідні дані, що його спричинили. Ви можете розглянути розмір пакета, паралелізм, довжину чи точність, зберігаючи мету проєкту. Будь-яке зменшення, що змінює оброблювані документи чи очікувані відповіді, вимагає нової перевірки якості; більше пам'яті може знадобитися, якщо ці обмеження потрібно зберегти.
Чи підтверджує наданий notebook працездатність мого застосунку інференсу?
Наданий notebook не підтверджує ваш застосунок: він вимірює невелику синтетичну мережу й пояснює лічильники пам'яті. Задокументований локальний тест стосується лише цього випадку. Ваш застосунок потрібно оцінювати з його моделлю, вхідними даними, середовищем та власними критеріями прийнятності, перш ніж робити будь-який висновок про ємність чи продуктивність.