Локальні LLM: яке обладнання та GPU дійсно потрібні

Юридична фірма з Варшави хотіла запустити асистента для аналізу договорів. Перше питання було технічним: чи вистачить сервера з відеокартою RTX 3090? Друге, точніше: яка модель взагалі потрібна для цієї задачі? Відповідь на перше залежить від відповіді на друге. Без вимог до моделі рішення щодо обладнання — це лотерея.

Нижче описано, як це поєднати — від вимог до моделі через обладнання до реального кошторису для польських компаній, які розглядають self-hosting LLM.

Локальний LLM можна запустити на CPU (наприклад, через llama.cpp), але швидкість генерації на самому процесорі зазвичай становить 2–8 токенів на секунду для моделі 7B. Для продакшн-застосунків, де користувач чекає на відповідь, ця швидкість занадто низька: людське сприйняття комфорту — це щонайменше 20–30 токенів на секунду.

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

VRAM (пам'ять GPU) визначає, чи завантажиться модель взагалі. Якщо модель не вміщається у VRAM, її переносять у RAM або на диск, а швидкість падає на порядок. Перше питання при виборі GPU завжди: чи вміститься вся модель у VRAM?

Memory bandwidth (пропускна здатність пам'яті) визначає, як швидко GPU зчитує ваги моделі під час генерації. Генерація кожного токена вимагає зчитування всієї моделі з пам'яті. Відеокарта з пропускною здатністю 800 ГБ/с генерує токен швидше, ніж карта з 400 ГБ/с при однаковій кількості ядер. Порівнюючи GPU, перевіряйте bandwidth, а не лише TFLOPS.

Потреба у VRAM залежить від розміру моделі та квантизації. Квантизація зменшує точність ваг з 16 бітів до 8, 4 або навіть 3 бітів, зменшуючи розмір моделі при прийнятному зниженні якості.

Значення приблизні; реальна потреба відрізняється залежно від довжини вікна контексту та реалізації. До наведених значень додається буфер для активацій: при контексті 8K це додаткові 1–2 ГБ, при 32K — 4–8 ГБ. Великі контексти швидко поглинають VRAM.

Ринок GPU у 2026 році можна поділити на три класи для застосувань LLM:

Споживчі карти (RTX серії 30xx/40xx) мають доступну ціну, але обмежений VRAM (до 24 ГБ у RTX 3090/4090). Пропускна здатність RTX 4090 становить 1 008 ГБ/с, що робить її найшвидшою доступною споживчою картою для LLM. Обмеження: відсутність підтримки NVLink для багатьох моделей, що ускладнює об'єднання карт. Ціна нової RTX 4090 — 8 000–10 000 zł.

Професійні карти (RTX A-series, L40S, RTX 6000 Ada) пропонують більше VRAM (48–80 ГБ), ECC, підтримку NVLink та драйвери для стабільного аптайму. RTX 6000 Ada (48 ГБ VRAM, ~24 000 zł) дозволяє запустити модель 34B у повній точності або 70B у Q4. L40S (48 ГБ) — це серверний аналог.

Карти дата-центрів (H100, A100, H200) пропонують найбільшу пам'ять (80–141 ГБ) та найвищу пропускну здатність (HBM3, ~3,35 ТБ/с для H100 SXM), але ціни починаються від 150 000 zł і зазвичай доступні лише в хмарі або через лізинг.

Для польських компаній, які хочуть запустити моделі 7B–13B для завдань RAG та класифікації, RTX 4090 або б/в RTX 3090 — це найкраще співвідношення ціни та можливостей. Для моделей 70B потрібні дві карти по 24 ГБ (NVLink або PCIe) або одна карта 48 ГБ+.

Дві відеокарти GPU можна об'єднати двома способами:

NVLink (лише для вибраних карт NVIDIA, включаючи RTX 3090/4090 з відповідною платою) об'єднує пам'ять обох карт в один пул. Модель 70B Q4 у 2×24 ГБ працює так, ніби має 48 ГБ єдиної пам'яті. Пропускна здатність комунікації становить ~600 ГБ/с, тому вузьке місце мінімальне.

PCIe (стандартні багатокартові конфігурації) не об'єднує пам'ять. Модель має вміщатися на одній карті або бути розділеною з передачею через шину PCIe (16 ГБ/с), що різко сповільнює інференс. Конфігурації PCIe multi-GPU корисні для пропускної здатності (багато паралельних запитів на різних картах), а не для роботи з однією великою моделлю.

Для продакшн-системи, що обслуговує багато паралельних запитів, конфігурація з 2–4 картами PCIe на одній моделі дозволяє збільшити кількість оброблених запитів на секунду без масштабування VRAM. Кожна карта обслуговує власну копію моделі; llm-router розподіляє трафік.

CPU та RAM відіграють другорядну, але не маргінальну роль.

Системна RAM потрібна для завантаження моделі у VRAM (модель спочатку зчитується в RAM, потім копіюється в GPU) та для обслуговування шару оркестрації: сервера API, RAG-пайплайну, препроцесингу запитів. Мінімум — подвійний обсяг VRAM, на практиці: 64 ГБ для однокартової конфігурації, 128 ГБ для multi-GPU.

CPU є вузьким місцем лише при роботі в режимі CPU-only (без GPU) або при інтенсивній попередній обробці (токенізація великих документів, ембедінги на CPU). Для обслуговування сервера API при GPU-прискореному інференсі достатньо будь-якого сучасного процесора серверного (наприклад, AMD EPYC, Intel Xeon) або десктопного класу (AMD Ryzen 9, Intel Core i9). Кількість ядер має значення для паралелізму API, а не для швидкості генерації.

SSD NVMe прискорює завантаження моделі при старті сервера. Модель 7B — це файл ~4 ГБ, а моделі 70B — 40 ГБ. Завантаження з HDD може займати кілька хвилин, з NVMe — кілька секунд. Для систем з багатьма моделями, що динамічно перемикаються (як наш OpenClaw router), швидкий диск скорочує час готовності.

Fine-tuning та квантизація — це два способи оптимізації моделі під обладнання. Квантизація — простіший шлях для більшості впроваджень.

Найпопулярніший формат у 2026 році — GGUF з квантизацією Q4_K_M або Q5_K_M (підтримується llama.cpp, Ollama, LM Studio). Q4_K_M зменшує VRAM на ~72% відносно BF16 при втраті якості 1–3% на загальних бенчмарках. Для спеціалізованих завдань (право, фінанси, медицина) варто тестувати емпірично — деградація може бути вищою для нішевих доменів, ніж показують загальні бенчмарки.

GPTQ та AWQ — це формати квантизації для карт NVIDIA, що працюють на рівні ядра GPU, швидші за GGUF при тому ж VRAM, але потребують компілятора та складнішого налаштування. Корисні для продакшн-серверів NVIDIA.

bitsandbytes 4-bit (QLoRA) використовується при fine-tuningu на GPU з обмеженим VRAM, а не для сервінгу. Не плутати з форматами інференсу.

Практичне правило: починайте з Q4_K_M, тестуйте якість на своєму наборі запитань і переходьте на Q5 або Q8 лише якщо бачите вимірне зниження точності. Для моделей 7B різниця між Q4 та Q8 зазвичай мінімальна для бізнес-завдань.

Рішення про локальний LLM — це фінансове рішення, а не лише технічне. Порівняння для типової польської реалізації:

Продуктивна конфігурація для моделі 13B: сервер з RTX 4090 (9 000 zł), 128 ГБ RAM (3 000 zł), AMD Ryzen 9 + материнська плата + блок живлення (5 000 zł), NVMe 2 ТБ (800 zł). Разом обладнання: ~18 000–22 000 zł одноразово. До цього потрібно додати час налаштування та адміністрування (зазвичай 2–4 дні інженерної роботи на старті, 1–2 години на тиждень для підтримки).

Споживання енергії RTX 4090 — ~350–400 Вт при повному навантаженні. За польськими тарифами на електроенергію (близько 0,80 zł/кВт·год) і 8 годинах роботи на день це близько 65–75 zł на місяць.

Порівняння з API в хмарі: при 100 000 коротких запитів на місяць (вхід ~200 токенів, вихід ~300 токенів) вартість API моделі класу GPT-4o становить близько 1 500–3 000 zł на місяць. Локальний LLM класу 13B обробляє ті ж запити лише за рахунок електроенергії (кілька десятків злотих) після окупності обладнання.

Поріг рентабельності локального LLM щодо хмарного API: при 100 000 запитах на місяць обладнання окупається за 6–12 місяців. При менш ніж 20 000 запитах на місяць хмарне API зазвичай дешевше з урахуванням часу адміністрування. Точний кошторис для вашого обсягу згенерує калькулятор інференсу.

Для багатьох польських компаній питання обладнання є вторинним щодо регуляторних вимог. RODO накладає обов'язок контролю над персональними даними, що обробляються системами AI. Якщо запити до LLM містять персональні дані (імена клієнтів, PESEL, адреси), відправлення їх до зовнішнього хмарного API вимагає, зокрема:

• укладення договору про доручення обробки даних (DPA) з постачальником API,
• перевірки, що сервери постачальника розташовані в ЄЕЗ або що існує відповідна правова підстава для передачі до третіх країн,
• проведення DPIA, якщо обробка є високоризиковою.

Self-hosting усуває ці вимоги для шару генерації: LLM працює на власній інфраструктурі, дані не залишають компанію. Це підхід детальніше описаний у статті про self-hosted LLM та RODO. Незалежно від вибору обладнання, PII має бути замасковане перед відправкою до моделі — це правило діє як для локального LLM, так і для API.

Опишіть свій випадок використання локального LLM (галузь, тип запитів, орієнтовний обсяг, чутливість даних), і модель підбере конфігурацію обладнання та вкаже оптимальну квантизацію (playground: PII маскуються, нульове зберігання):

RTX 4090 з 24 ГБ VRAM підтримує моделі до 13B у повній точності або моделі до 34B у квантизації Q4. Для більшості бізнес-застосунків — асистенти RAG, класифікація документів, відповіді на FAQ — моделі 7B або 13B достатньо, а RTX 4090 генерує їх зі швидкістю 50–80 токенів на секунду. Якщо вам потрібна модель 70B (наприклад, для складнішого міркування), знадобиться або дві карти з NVLink, або карта 48 ГБ+.

Модель 70B у квантизації Q4_K_M займає близько 40–42 ГБ VRAM. До цього додається буфер для контексту: при вікні 8K це 2–4 ГБ, при 32K — 8–12 ГБ. Мінімальне обладнання — дві карти RTX 3090/4090, об'єднані NVLink (сумарно 48 ГБ), або одна професійна карта 48 ГБ, наприклад, RTX 6000 Ada або L40S. Конфігурація з двома картами PCIe не об'єднує пам'ять, тому модель 70B Q4 не вміститься на 2×24 ГБ без NVLink.

Так, інструменти на кшталт llama.cpp дозволяють запустити LLM виключно на CPU. Однак швидкість генерації становить 2–8 токенів на секунду для моделей 7B, що для продакшн-застосунків (чат, асистент) занадто повільно. Режим CPU корисний для тестування, прототипування та пакетних завдань без часових обмежень (наприклад, overnight batch summarization). Для продуктивної пропускної здатності GPU є обов'язковим.

Q4_K_M зменшує VRAM більш ніж удвічі порівняно з повною точністю при втраті якості 1–3% на загальних бенчмарках. Q8 зменшує VRAM на ~50% при втраті менше 1%. Рекомендована відправна точка — Q4_K_M: вона дозволяє вмістити більше моделі у доступний VRAM, і в більшості бізнес-завдань різниця в якості несуттєва. Переходьте на Q5 або Q8 лише тоді, коли виміряєте конкретне зниження точності на власному тестовому наборі, а не на основі абстрактних бенчмарків. Вибір базової моделі та квантизації описано у статті про витрати local vs API LLM.

Найпопулярніші варіанти у 2026 році: Ollama (найпростіша установка, API сумісне з OpenAI, підтримує GGUF), vLLM (продуктивний сервер для GPTQ/AWQ, оптимізований під пропускну здатність, вимагає CUDA), llama.cpp з HTTP-сервером (гнучкий, підтримує CPU та GPU, формат GGUF) та LM Studio (графічний інтерфейс для прототипування). Для продакшн-середовищ Ollama або vLLM з llm-router для управління трафіком та фолбеком до хмари при перевантаженні — це перевірена практика. Деталі архітектури описано у статті про корпоративний GPT на базі знань.