LLM Вимоги до сервера: GPU VRAM, RAM і сховище за розміром моделі

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

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

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

Комерційні варіанти, на які посилається цей посібник: сервери AI (https://unihost.com/dedicated/ai-servers/); GPU сервери (https://unihost.com/dedicated/gpu/); виділені сервери (https://unihost.com/dedicated/)

Пов’язана інформація про Unihost: керівництво з апаратного забезпечення сервера ШІ (https://unihost.com/blog/ai-servers-2025-hardware/); CPU проти GPU проти RAM для ШІ (https://unihost.com/blog/choosing-server-specs-ai/); GPU сервери для ШІ та машинного навчання (https://unihost.com/blog/gpu-dedicated-servers-for-ai-machine-learning/)

LLM вимоги до сервера для висновків проти навчання

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

Збирайте формат моделі, маркери на запит, довжину контексту, розмір пакета, одночасні послідовності, час до першого маркера, кількість маркерів за секунду та використання GPU під час звичайного трафіку та під час типового піку. Порівняйте мітки часу інфраструктури з трасуванням програми, щоб команда могла підключити повільний запит або невдале завдання до ресурсу, який був обмежений. Середні показники корисні для планування витрат, але p95, p99 і зростання черги показують, чи короткі спалахи вже шкодять службі.

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

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

Як параметри, точність і квантування впливають на VRAM для LLM

Вага пам’яті – це приблизно кількість параметрів, помножена на байти на параметр. FP16 або BF16 використовує близько двох байтів на параметр, 8-бітний приблизно один і 4-бітний приблизно півбайта перед накладними витратами на форматування. Квантування зменшує вагу пам’яті, але якість, підтримку ядра та швидкість повинні бути перевірені з вибраним часом виконання.

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

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

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

Таблиця розмірів серверів AI за класом моделі

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

Використовуйте фактичний розподіл VRAM під час простою та під навантаженням, зростання кеш-пам’яті KV, зайнятість пакетів і події нестачі пам’яті як модель невеликої ємності, а не знімок інформаційної панелі. Розділіть постійний попит, планову роботу та виняткові піки. Модель повинна пояснювати, який ресурс насичується першим, як довго триває насиченість і який клієнт або операційний результат змінюється в цей момент.

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

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

Діапазони планування для квантованого LLM VRAM

Перегляньте готові до ШІ сервери GPU.

CPU, системні RAM, NVMe та вимоги до мережі

GPU не усуває потреби у збалансованому хості. CPU обробляє токенізацію, маршрутизацію запитів і попередню обробку. Система RAM зберігає файли моделі, кеш сторінок, CPU розвантаження та кілька робітників. NVMe для ШІ скорочує завантаження моделі та підтримує векторні індекси або набори даних. Мережа має значення для API трафіку, розподілу моделі та багатовузлового зв’язку.

Вимірюйте CPU насиченість під час токенізації, пік RAM хоста, час завантаження моделі, NVMe пропускну здатність і затримку, мережеву передачу та GPU паузи в режимі простою з достатньою роздільною здатністю для захоплення пакетів і достатньою тривалістю для виявлення витоків, ефектів кешу та фону робочих місць. Тримайте поєднання робочого навантаження видимим. Тест, в якому переважають легкі запити, може повідомити про хороші середні значення, тоді як дорогий шлях уже стоїть у черзі.

Запобігайте виснаженню LLM висновку GPU шляхом зіставлення CPU смуг, RAM каналів, PCIe топології та пам’яті з кількістю прискорювача. Не ігноруйте поєднання дорогого GPU із замалою системою RAM, повільним накопичувачем або недостатнім PCIe підключенням. Підтвердьте рекомендацію за допомогою холодного старту, перезавантаження моделі, одночасних запитів і тестів прийому даних. Запишіть, яке припущення має найнижчу достовірність, і спочатку повторно перевірте це припущення, коли зміниться трафік, дані або програмне забезпечення.

Зберігайте ефективність програмного забезпечення в моделі. Плани запитів, політика кешу, обмеження стиснення, пакетування та паралелізму можуть змінити потребу в ресурсах більш ніж на одному апаратному рівні. Повторно запустіть той самий набір доказів після налаштування, щоб остаточна покупка відображала вдосконалену систему, а не дефект, якого можна уникнути.

Одинарний GPU проти кількох GPU і паралелізму

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

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

Віддавайте перевагу незалежним копіям для пропускної здатності, коли модель відповідає одному GPU; використовуйте паралелізм моделі, коли цього вимагає обсяг пам’яті. Найдорожчою помилкою було б додати графічні процесори без двигуна, який ефективно масштабується, або без достатньої CPU і мережевої потужності для їх живлення. Зменште цю невизначеність за допомогою одного GPU і кількох GPU тестів за однакової якості, контексту та паралельності. Зберігайте шлях оновлення або відкоту, який не залежить від уже обмеженого компонента.

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

Приклади профілів для розробки, виробництва API і високого паралелізму

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

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

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

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

Довідкові профілі висновків

Порівняйте сервери AI (https://unihost.com/dedicated/ai-servers/) і GPU сервери (https://unihost.com/dedicated/gpu/).

Перелік витрат, конфіденційності даних і керування

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

Збирайте вартість прийнятої відповіді, GPU використання, години простою, навантаження інцидентів, вік виправлення, події доступу та збереження даних під час звичайного трафіку та під час типового піку. Порівняйте мітки часу інфраструктури з трасуванням програми, щоб команда могла підключити повільний запит або невдале завдання до ресурсу, який був обмежений. Середні значення корисні для планування витрат, але p95, p99 і зростання черги показують, чи короткі спалахи вже шкодять службі.

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

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

Запит конфігурації робочого навантаження ШІ

Поширені й відповіді

Скільки VRAM потрібно LLM?

Почніть із кількості параметрів, помноженої на байти на параметр, а потім додайте робочу область часу виконання та кеш KV для контексту та паралельності. 4-розрядна модель використовує приблизно половину байта на параметр перед накладними витратами на форматування. Перевірте точну модель і двигун, оскільки практичний розподіл відрізняється.

Чи може LLM працювати лише на CPU?

Так, особливо менші квантовані моделі та завдання з низькою пропускною здатністю. Висновок CPU зазвичай повільніший і може потребувати значної системи RAM, але він може підійти для розробки, пакетної роботи або чутливих до конфіденційності служб без суворої затримки. Порівняйте цільову модель на точному CPU.

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

Система RAM має охоплювати OS, файли моделі, кеш сторінок, CPU розвантаження, попередню обробку та робочі елементи. Багато одноGPU проектів починаються приблизно з 64-128 ГБ, тоді як більшим або багатоGPU системам може знадобитися 256 ГБ або більше. Вимірювання пікового розподілу хостів під час реалістичного паралелізму.

Коли потрібен мультиGPU сервер?

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