Найкращі хмарні GPU для обслуговування та розгортання великих мовних моделей

Що насправді вимагає обслуговування LLM від орендованої GPU

Обслуговування великої мовної моделі — це принципово інше навантаження, ніж її навчання. Навчання орієнтоване на пропускну здатність і терпиме до затримок; обслуговування чутливе до затримок, обмежене пам’яттю і має сплески навантаження. Коли ви орендуєте GPU для розгортання LLM за API, вузьким місцем рідко є сирі FLOPS. Важливіше, скільки моделі та її KV кешу ви можете розмістити у VRAM, наскільки швидко ця пам’ять передає дані і скільки одночасних запитів ви можете обробити пакетно, перш ніж кількість токенів за секунду на користувача впаде.

KV кеш — це те, що більшість недооцінює. Кожен активний запит зберігає ключі та значення уваги для свого контексту, і цей слід зростає з довжиною послідовності та кількістю одночасних користувачів. Модель, яка комфортно працює в стані простою, може вичерпати пам’ять у момент, коли ви запускаєте реальний трафік з довгими підказками. Саме тому для розгортання обслуговування часто потрібен більший запас VRAM, ніж це випливає лише з ваг моделі.

Як підібрати GPU під модель

Практичне перше питання — чи поміщається модель на одному GPU, чи її потрібно розподіляти на кілька. Порівнюючи вищезазначене з вашою моделлю, врахуйте такі фактори:

• Об’єм VRAM визначає, які моделі поміщаються. Квантизована модель 7B–13B у FP8 або INT8 може обслуговуватися з одного середнього прискорювача, тоді як модель 70B у BF16 зазвичай потребує карти з великою пам’яттю або вузла з кількома GPU. Дуже великі моделі класу frontier фактично вимагають кількох топових GPU, з’єднаних між собою.
• Пропускна здатність пам’яті визначає швидкість генерації токенів. Автогресивне декодування читає повний набір ваг для кожного згенерованого токена, тому пам’ять класу HBM (як на картах для дата-центрів) генерує токени значно швидше, ніж споживчі карти з GDDR при однаковому розмірі моделі. Для інтерактивного чату пропускна здатність часто важливіша за обчислювальну потужність.
• Підтримувані точності визначають, наскільки агресивно можна стискати модель. Карти з підтримкою тензорних операцій у FP8 та INT8 дозволяють обслуговувати більші моделі з меншою VRAM і вищою пропускною здатністю, за умови сумісності стеку обслуговування та схеми квантизації моделі.
• Інтерконнект має значення, коли модель розподілена між кількома GPU. Тензорне паралельне обслуговування обмінюється активаціями між GPU на кожному шарі, тому з’єднання класу NVLink всередині вузла забезпечують суттєво кращу затримку, ніж конфігурації лише з PCIe. Для розгортання на одному GPU інтерконнект не має значення.

Обслуговування на одному GPU проти багатьох GPU

Якщо ваша модель і її піковий KV кеш поміщаються на одному GPU, залишайте їх там. Обслуговування на одному GPU повністю уникає накладних витрат на міжпристрійне спілкування і простіше в експлуатації. Перейдіть до тензорного паралелізму або розгортання на кількох вузлах лише тоді, коли модель справді не поміщається, оскільки кожен доданий GPU додає вартість синхронізації і ускладнює автоскейлінг. Коли потрібні кілька GPU, віддавайте перевагу інстансам зі списку вище, які поєднують карти з великою пам’яттю та швидкий внутрішньовузловий інтерконнект, а не збирають розрізнені карти.

Особливості провайдера, важливі для обслуговування, а не навчання

Окрім кремнію, операційна модель провайдера визначає, чи є розгортання життєздатним. При перегляді порівняння вище для навантаження обслуговування, а не навчання, пріоритети інші:

• Час холодного старту та налаштування стають першочерговими питаннями. Кінцева точка обслуговування, яка масштабується до нуля між піками трафіку, платить за холодний старт при кожному масштабуванні вгору, тому швидке розгортання та кешування образів безпосередньо впливають на затримку на хвості.
• Гранулярність білінгу змінює економіку сплесків трафіку. Оплата за секунду чи хвилину підходить для кінцевих точок з автоскейлінгом, які запускають і зупиняють інстанси; грубий погодинний білінг карає таку модель.
• Надійність on-demand над spot зазвичай є правильним вибором. Переривні або spot-інстанси чудові для навчання та пакетних завдань, але ризиковані для кінцевої точки, орієнтованої на користувача, де відбір посеред запиту призведе до втрати живого трафіку. Spot все ще добре підходить для неінтерактивного пакетного інференсу.
• Постійне зберігання та швидке завантаження моделі зменшують біль від перезапусків. Ваги розміром у кілька гігабайт, які завантажуються з холодного об’єктного сховища при кожному перезапуску, додають хвилини простою; кешовані або приєднані томи скорочують цей час.
• Мережа та вихідний трафік впливають на вартість у масштабі. Інференс з високою пропускною здатністю може передавати багато даних; перевірте умови вихідного трафіку перед тим, як зобов’язуватися на розгортання з великим трафіком.

Пакетне проти реального часу і де лежать витрати

Визначте на початку, який режим ви оптимізуєте. Обслуговування в реальному часі цінує низький час до першого токена і стабільну швидкість токенів на користувача, що віддає перевагу пам’яті з великою пропускною здатністю та помірним розмірам пакетів. Пакетний або офлайн інференс цінує загальну пропускну здатність і може обробляти великі пакети на дешевшому або переривному обладнанні, жертвуючи затримкою на запит заради значно кращої вартості за токен. Багато команд використовують обидва підходи: швидкий on-demand рівень для живих користувачів і spot-підтримуваний пакетний рівень для масового генерування.

Щодо вартості оренди, обслуговування охоплює весь спектр. Невелика квантизована модель на середній карті недорога і широко доступна; frontier-моделі на багатокарткових вузлах з великою пам’яттю — рідкісні, дорожчі і іноді обмежені в потужностях під час пікових навантажень. Оскільки тарифи постійно змінюються і залежать від регіону та зобов’язань, розглядайте наведене вище порівняння як джерело істини, а не будь-яке фіксоване число, і порівнюйте інстанси за VRAM, класом пропускної здатності, інтерконнектом і моделлю білінгу разом, а не лише за загальною ціною.

Часті запитання

Скільки VRAM потрібно для обслуговування LLM?

Розраховуйте на ваги моделі у вибраній точності плюс значний запас для KV кешу, який зростає з довжиною контексту та кількістю одночасних користувачів. Орієнтовно, квантизовані малі та середні моделі обслуговуються з однієї середньої карти, тоді як великі моделі у вищій точності потребують карти з великою пам’яттю або кількох GPU. Завжди розраховуйте на пікову одночасність, а не на стан простою.

Чи підходять spot або переривні GPU для обслуговування LLM?

Для кінцевих точок у реальному часі, орієнтованих на користувача, зазвичай ні, оскільки відбір може призвести до втрати живих запитів і примусового холодного перезапуску. Spot-інстанси добре підходять для офлайн або пакетного інференсу, де переривання лише затримують пропускну здатність, а не руйнують інтерактивну сесію. Багато команд зберігають on-demand потужності для живого трафіку і використовують spot для масових завдань.

Чому пропускна здатність пам’яті важливіша за обчислення для обслуговування?

Декодування токен за токеном читає ваги моделі з пам’яті для кожного згенерованого токена, тому швидкість генерації обмежена тим, наскільки швидко GPU передає дані з пам’яті, а не його піковими FLOPS. Ось чому карти з HBM для дата-центрів генерують токени швидше, ніж споживчі карти з тією ж моделлю, і чому пропускна здатність пам’яті є ключовим параметром для порівняння вище.

Чи варто обслуговувати на одному GPU чи розподіляти на кілька?

Використовуйте один GPU, коли модель і її піковий KV кеш поміщаються, оскільки це уникає міжпристрійного спілкування і спрощує масштабування. Перейдіть до багатьох GPU з тензорним паралелізмом лише тоді, коли модель справді не поміщається, і обирайте інстанси, які поєднують карти з великою пам’яттю та швидкий внутрішньовузловий інтерконнект.