У популярного каналу Tech With Tim вийшов докладний гайд про локальний agentic‑кодинг без хмари — з моделями, що працюють прямо на комп’ютері розробника. Ключова частина цієї постановки — правильно підібрана LLM: така, яку ваш ПК або Mac реально “тягне” по пам’яті й пропускній спроможності. Від цього залежить не тільки те, чи модель взагалі запуститься, а й те, чи буде вона працювати зі швидкістю, придатною для щоденного кодування.
У центрі обговорення — кілька простих, але критичних для практики тез: роль VRAM та unified memory, орієнтири по кількості параметрів, пастка “модель трохи більша за вашу відеопам’ять” і значення quantization для розміру та швидкості.
VRAM як головний лімітатор: одне число вирішує все
Для хмарних моделей комп’ютер користувача майже неважливий — основне навантаження лягає на віддалені GPU‑кластери. У локальному сценарії все навпаки: продуктивність і сам факт того, яку саме модель можна запустити, визначає апаратне забезпечення.
Критичний параметр — відеопам’ять. Вона фактично задає “стелю” для розміру моделі, яку комп’ютер здатен ефективно тримати цілком у GPU.
У розмові це формулюється максимально прямо: тип або, точніше, розмір моделі, яку можна запускати локально, практично повністю диктується одним числом — обсягом відеопам’яті, VRAM. Для Windows‑машин це означає: потрібно подивитися саме на GPU та його VRAM, а не на загальну системну RAM.
Звідси випливає практичне правило: якщо на відеокарті 16 GB VRAM, можна ефективно запускати модель приблизно до 16 GB за розміром, краще — трохи меншу, щоб залишити запас. Саме цей “ефективно” є ключовим: важливо не просто завантажити модель, а зробити так, щоб вона працювала без катастрофічних просідань у швидкості.
Mac проти Windows: unified memory, доступний обсяг і швидкість
Для Windows та дискретних GPU (NVIDIA тощо) картина доволі пряма: є чітко окреслений обсяг VRAM, і саме він обмежує розмір моделі, що поміститься в GPU цілком. На Mac, особливо з чипами серії M, ситуація відрізняється через unified memory.
На сучасних M‑процесорах RAM є спільною для CPU та GPU. Якщо ноутбук має 64 GB unified memory, теоретично GPU може використати весь цей обсяг як “відеопам’ять”. На практиці частина пам’яті йде на операційну систему й інші процеси, тому орієнтовно доступними для моделі будуть 75–80% цієї пам’яті.
Це породжує два важливі висновки.
По‑перше, при плануванні розміру моделі на Mac доводиться відняти приблизно 10–15% від загального обсягу unified memory: це верхня межа, за якої ще можна розраховувати на пристойну продуктивність. Наприклад, із 64 GB на борту реалістично розраховувати на модель суттєво меншого розміру, а не на повні 64 GB.
По‑друге, попри те, що Mac завдяки unified memory часто здатен завантажувати більші моделі, швидкість не завжди буде кращою. Для дискретних GPU на Windows пропускна спроможність пам’яті зазвичай вища. На конкретних прикладах порівнюється, що сучасний високорівневий GPU дає помітно більшу швидкість читання/запису пам’яті, ніж Mac‑чип. Наслідок: Mac може дозволити собі більший розмір моделі, але виділений GPU частіше забезпечить більше токенів за секунду.
Це і є розмежування “можливостей” та “швидкості”: один комп’ютер може тримати більшу модель, але інший, хоч і з меншим лімітом, генеруватиме токени суттєво швидше.
Що станеться, якщо модель більша за VRAM
Одна з найбільш практичних частин пояснення стосується сценарію, коли модель за розміром виходить за межі доступної відеопам’яті. Формально це не завжди фатально: якщо модель важить 10 GB, а GPU має лише 8 GB VRAM, система здатна все одно її завантажити.
Проте відбувається те, чого більшість користувачів не бачать, але відчувають як “чому воно раптом стало жахливо повільним”. Надлишкові 2 GB, які не вмістилися в VRAM, переміщуються в системну пам’ять, а в гірших випадках — навіть на диск, залежно від того, як організовано завантаження.
Це кардинально змінює швидкість. У бесіді чітко підкреслюється, що така модель може працювати в сто разів повільніше, ніж коли вона повністю вміщується у відеопам’ять. Формулювання жорстке, але показує масштаб проблеми: технічно модель “працює”, але практичною вона перестає бути.
Висновок простий: якщо очікується хоч якась продуктивність, варто запускати лише моделі, розмір яких менший за доступну VRAM. Інакше локальний AI‑кодинг перетворюється на очікування відповідей, що триває хвилинами.
Скільки параметрів потягне ваш ПК
У розмові пропонується орієнтовний “чіт‑шит” відповідності між обсягом VRAM і кількістю параметрів моделі. Це не жорсткі межі, а радше практичні рекомендації, які допомагають не заблукати серед варіантів.
Логіка така: чим більше параметрів, тим більший розмір файлу моделі і тим більше пам’яті вона потребує. У прикладах звучать типові конфігурації:
якщо є 8 GB VRAM, зазвичай можна запускати модель з 7 мільярдами параметрів;
12–16 GB VRAM відкривають шлях до моделей на рівні 14B;
24 GB дозволяють працювати з моделями близько 32B;
64 GB і більше — це вже рівень, де стають реалістичними моделі приблизно на 70B параметрів.
Одразу робиться застереження: це загальний орієнтир, а не математично точна пропорція. Реальний розмір файлу моделі з певною кількістю параметрів залежить від того, як її налаштовано й у якій формі вона постачається, включно з рівнем quantization. Однак як “перший фільтр” при виборі моделі ці числа працюють добре.
Quantization: трохи якості в обмін на швидкість і розмір
Ще один ключовий шар локального вибору моделі — quantization. У практичній площині це набір варіантів однієї й тієї ж моделі з різними “Q‑рівнями”: повна версія без стиснення, потім варіанти Q6, Q4, Q3, Q2 тощо.
Суть у тому, що quantization стискає модель, зменшуючи внутрішню точність представлення параметрів. У результаті майже завжди втрачається невелика частина якості, зате різко зменшується розмір файлу і, відповідно, обсяг пам’яті, потрібний для завантаження.
Позиція, яка чітко звучить у розборі, доволі прагматична: майже завжди краще брати найнижчу версію quantization, яку ваш комп’ютер здатен запускати. Аргументація проста. Втрата якості невелика, зате виграш у розмірі та швидкості — суттєвий. Менша модель швидше генерує токени і краще вписується в VRAM, що дозволяє уникнути згаданого вище сценарію з “витіканням” частини параметрів у RAM чи на диск.
У конкретному прикладі розглядається модель із 35 мільярдами параметрів, у якої повна версія займає 37 GB, а Q4 — помітно менше. Вибір падає саме на Q4, бо вона без проблем поміщається в доступну пам’ять і працює “відчутно швидше”, ніж більш важка повна модифікація.
Параметри проти пропускної здатності: де проходить реальний компроміс
За межами чисто пам’ятних обмежень залишається ще один фактор — пропускна спроможність пам’яті та швидкість генерації токенів. Тут знову постає різниця між Mac і Windows, але вже під іншим кутом.
Mac із великою unified memory може завантажувати більші моделі, та при цьому пропускна спроможність GPU‑пам’яті на високорівневих дискретних картках Windows, як правило, вища. Це приводить до того, що більша модель на Mac не обов’язково буде “кращою”, якщо на практиці вона генерує відповіді повільніше, ніж трохи менша, але швидша модель на потужному GPU.
Ця думка наголошується окремо: існує різниця між швидкістю і можливостями. Більша модель — не завжди кращий вибір, так само як і менша — не обов’язково гірша. Контекст визначає, що важливіше: максимальна “мозковитість” моделі чи комфортна швидкість відповіді в робочому циклі розробника.
Висновок: від VRAM до Q‑рівня — як зібрати реалістичний профіль моделі
Розмова про локальний agentic‑кодинг показує, що успіх такої конфігурації починається не з редакторів або інструментів, а з тверезого погляду на власне “залізо”. Кілька базових правил випливають безпосередньо з практики:
спочатку визначити обсяг VRAM або доступної unified memory, а для Mac — одразу прийняти, що реально використати вдасться близько 75–80%;
підбирати модель так, щоб її розмір був меншим за VRAM, уникаючи ситуацій, коли частина параметрів опиняється в системній RAM чи на диску;
орієнтуватися на приблизну відповідність “8 GB VRAM — 7B параметрів, 12–16 GB — 14B, 24 GB — 32B, 64 GB+ — близько 70B”, пам’ятаючи, що це саме орієнтири;
свідомо використовувати quantization і віддавати перевагу найнижчому Q‑рівню, який ваш комп’ютер тягне комфортно, бо це майже завжди дає кращий баланс між якістю, розміром і швидкістю.
У підсумку локальний AI‑асистент для коду розглядається не як абстрактна “найсильніша модель”, а як конкретний профіль: розмір, рівень quantization, кількість параметрів і те, наскільки все це співвідноситься з VRAM і пропускною спроможністю саме вашої машини. Саме такий підхід дозволяє перетворити локальні LLM із лабораторної іграшки на інструмент, придатний для щоденної роботи.
Джерело
YouTube: The Best LOCAL Agentic Coding Workflow (Complete Guide)