Навіщо self-hosted розгортання?
Розгортання великих мовних моделей (LLM) на власній інфраструктурі дає більше контролю над даними, спрощує відповідність вимогам безпеки та комплаєнсу і дозволяє уникнути передачі чутливої інформації через зовнішні API. Для сценаріїв із великим і стабільним навантаженням self-hosted підхід може бути економічно вигідним у довгостроковій перспективі — але це залежить від повного TCO (GPU/хмара, енергія, підтримка, SLA, вимоги до latency/throughput).
Сімейство моделей Llama від Meta залишається однією з найпопулярніших open-weight лінійок для локального розгортання. У цій статті розберемо обидві актуальні лінійки: Llama 3.x (релізи 2024 року) та Llama 4 (квітень 2025), їхні апаратні вимоги та критерії вибору під корпоративні завдання.
Огляд екосистеми Llama 3.x: від 1B до 405B параметрів
Meta у 2024 році випустила кілька поколінь моделей, кожне з яких орієнтоване на різні сценарії:
Llama 3.2 (1B та 3B, text-only)
Легкі моделі, оптимізовані для on-device / edge-розгортання та завдань із помірними вимогами до якості: базова класифікація, простий чат-асистент, маршрутизація запитів.
Примітка: у офіційних quantized-релізах контекст може бути зменшений (до ~8K), що варто враховувати для RAG та довгих діалогів.
Llama 3.1 (8B)
Універсальна модель для широкого спектра NLP-завдань: генерація тексту, короткі/середні діалоги, витягування сутностей, допоміжні RAG-сценарії. Часто є оптимальним стартом для self-hosted, якщо потрібна якість вище за 1B/3B без великих витрат на інфраструктуру.
Llama 3.2 Vision (11B та 90B, мультимодальні)
Перші мультимодальні моделі лінійки Llama: image + text → text. Підходять для аналізу документів (скани), інтерпретації графіків та скріншотів, visual Q&A.
Примітка: Llama 4 (Scout та Maverick) вже нативно мультимодальні й у більшості задач перевершують ці моделі — для нових проєктів варто одразу розглядати Llama 4.
Llama 3.3 (70B)
Модель класу 70B, орієнтована на високу якість відповіді в інструктивних сценаріях. Підтримує контекстне вікно до 128 000 токенів.
Ключова перевага: Llama 3.3 70B забезпечує якість, порівнянну з Llama 3.1 405B, при значно менших апаратних витратах. Це часто робить її основним вибором для корпоративних RAG-систем і генерації коду, де 8B вже недостатньо, а 405B — надто дорого. Підтримує 8 мов: англійська, французька, німецька, іспанська, португальська, хінді, італійська, тайська.
Примітка: Llama 3.3 — це text-only модель (текст на вході та виході). Зображення вона не обробляє.
Llama 3.1 (405B)
Найбільша модель лінійки (405 млрд параметрів) із контекстним вікном до 128K токенів. Використовується переважно як «teacher model» для генерації синтетичних даних та distillation — коли велика модель генерує приклади для fine-tuning менших та дешевших моделей під специфічні потреби компанії.
Llama 4: наступне покоління
5 квітня 2025 року Meta випустила Llama 4 Scout та Llama 4 Maverick — перші open-weight нативно мультимодальні моделі з MoE-архітектурою (Mixture-of-Experts). Це принципово нова архітектура порівняно з густими (dense) трансформерами Llama 3.x.
Llama 4 Scout
Scout має 109B загальних параметрів з 16 експертами та 17B активних параметрів на токен. Головна особливість — контекстне вікно до 10 мільйонів токенів, що відкриває нові можливості: аналіз цілих кодових баз, юридичних архівів, розширені RAG-сценарії без чанкування. У квантованому вигляді (INT4) поміщається на один NVIDIA H100.
Llama 4 Maverick
Maverick має 400B загальних параметрів з 128 експертами та 17B активних параметрів на токен. Контекстне вікно — до 1M токенів. Орієнтований на максимальну якість: перевершує GPT-4o та Gemini 2.0 Flash у кодуванні, мультимодальних завданнях та multilingual-сценаріях. Завдяки MoE-архітектурі інферує швидше, ніж dense-модель аналогічного розміру.
Ліцензування
Кожна версія Llama має окрему ліцензію: Llama 3.1 Community License, Llama 3.3 Community License, Llama 4 Community License. Усі дозволяють комерційне використання за умови дотримання Acceptable Use Policy від Meta.
Важливо для Llama 4: якщо ваші сервіси перевищують 700 мільйонів активних користувачів на місяць — потрібна окрема ліцензія від Meta.
Апаратні вимоги: VRAM для інференсу
Ключовий ресурс при розгортанні LLM — VRAM. Структура витрат пам’яті складається з трьох частин: ваги моделі (залежать від кількості параметрів і precision), KV-cache (залежить від довжини контексту та кількості паралельних запитів) та оверхед рушія / фреймворку.
Вимоги до VRAM за моделлю та форматом точності
| Модель | FP16/BF16 (лише ваги) | FP8/INT8 | INT4 | Рекомендована конфігурація |
|---|---|---|---|---|
| 8B (Llama 3.1 / 3.2) | ~16ГБ | ~8ГБ | ~4ГБ | 1× NVIDIA L4 / A10G |
| 70B (Llama 3.1 / 3.3) | ~140ГБ | ~70ГБ | ~35ГБ | 2–4× A100 / H100 |
| 405B (Llama 3.1) | ~810ГБ | ~405ГБ | ~200+ГБ | 8× H100 / A100 (кластер) |
| Scout (Llama 4, 109B) | ~218ГБ | ~109ГБ | ~55ГБ | 4× H100 (full); 1× H100 (INT4) |
| Maverick (Llama 4, 400B) | ~800ГБ | ~400ГБ | ~200ГБ | 5–7× H200 / H100 (кластер) |
Примітка 1: Якщо у вас довгий контекст (десятки тисяч токенів) і багато паралельних запитів — KV-cache може «з’їсти» більше VRAM, ніж самі ваги. Оцінюйте не лише «чи влізе модель», а й який concurrency та max context ви плануєте.
Примітка 2: MoE-моделі (Llama 4): потребують ~2 ГБ VRAM на 1B загальних параметрів, але активних параметрів на токен значно менше — тому інференс швидший за dense-аналоги аналогічного розміру.
Оптимізація інференсу замість нарощування обладнання
Для продуктивного self-hosted розгортання зазвичай вигідніше оптимізувати інференс, ніж «просто додати GPU». Найпоширеніші рушії — vLLM, Text Generation Inference (TGI), TensorRT-LLM від NVIDIA.
- Квантування (Quantization). Переведення ваг у lower precision (INT8/INT4 тощо) або схеми AWQ/GPTQ/GGUF. Зменшує VRAM та підвищує throughput. Компроміс — можливе падіння якості, яке обов’язково потрібно перевіряти на ваших кейсах.
- PagedAttention / ефективна робота з KV-cache. Зменшує фрагментацію пам’яті і дозволяє тримати більше паралельних запитів без OOM. Популярне в vLLM.
- Continuous Batching. Динамічне «підмішування» нових запитів у батч під час інференсу — GPU не простоює між запитами.
- Tensor Parallelism. Для 70B+ моделей обчислення розподіляються між кількома GPU. Обов’язкова умова для прийнятної latency та стабільності під навантаженням.
Критерії вибору для конкретних бізнес-завдань
Рекомендовані моделі за типом бізнес-завдання
| Завдання | Рекомендована модель | Причина |
|---|---|---|
| Класифікація, маршрутизація, короткі відповіді | Llama 3.2 1B/3B або Llama 3.1 8B | Мінімальні витрати, легке масштабування |
| Аналіз зображень, сканів, графіків, PDF | Llama 3.2 Vision 11B/90B або Llama 4 Scout/Maverick | Нативна підтримка image+text |
| Корпоративний RAG, генерація коду, складні відповіді | Llama 3.3 70B або Llama 4 Scout | Найкращий баланс якості та вартості |
| Синтетичні дані, дистиляція, teacher model | Llama 3.1 405B або Llama 4 Maverick | Максимальна якість для fine-tuning |
| Дуже довгі контексти (100K+ токенів, codebase, архіви) | Llama 4 Scout (до 10M токенів) | Революційно більше вікно контексту |
Підсумок
Self-hosted розгортання Llama — це інженерний баланс між розміром моделі, precision/квантуванням, довжиною контексту, паралельністю запитів і підходом до serving. Вдалий вибір дозволяє бізнесу краще контролювати дані, прогнозувати витрати та уникати постійної оплати за токени зовнішнім провайдерам у сценаріях із великим навантаженням.
Успішне впровадження потребує комплексного розуміння ML-pipeline — від підготовки даних до продуктивного розгортання. Для тих, хто хоче освоїти весь цей стек, спеціалізація Machine Learning & AI може стати наступним кроком.