Останні місяці локальні мовні моделі зробили стрибок уперед: вони стали «неймовірно хорошими і відносно простими в запуску» — настільки, що сьогодні розробник може організувати повністю локальний agentic‑кодинг без інтернету, без API‑ключів і без оплати за токени. Канал Tech With Tim показує це на практиці, збираючи повний стек з LM Studio та Visual Studio Code.
Йдеться не просто про «запустити LLM на ноутбуці», а про повноцінний робочий процес: модель уміє виконувати завдання, створювати й редагувати файли, викликати інструменти, а сам кодинг відбувається в знайомому IDE. Нижче — як вибудовується цей стек, які компроміси доводиться приймати й для кого такий підхід реально замінює хмарні моделі.
Чому локальні моделі раптом стали практичними
Класичний agentic‑кодинг сьогодні — це звернення до потужних хмарних LLM‑ів, що працюють на серверах із терабайтами RAM і пачкою GPU. По суті, під час автодоповнення коду, генерації функцій чи виконання агентних задач розробник просто «орендує» чужий обчислювальний кластер через API.
Локальний підхід перевертає цю модель: усі обчислення відбуваються на власному комп’ютері. Немає запитів у хмару, немає зовнішнього сервера, немає білінгу за кожен токен. «Коли ви використовуєте локальну модель, все на вашому власному комп’ютері… ви не платите за жодний compute… можете запускати її нескінченну кількість разів».
Це радикально змінює економіку використання AI‑інструментів для розробки: можна без обмежень тестувати ідеї, проганяти великі серії рефакторингів, не рахуючи запити. Водночас з’являється й нове обмеження — продуктивність ПК.
Опус не потягнемо: апаратні межі локального AI
Ключовий компроміс локальних LLM — якість проти заліза. Хмарні моделі «опус‑рівня» тримаються на масивних кластерах, і перенести їх на звичайний ноутбук сьогодні неможливо.
«Ми не здатні запускати Opus‑рівень моделей на нашому комп’ютері. Ми можемо запускати ті, що близькі до Sonnet або Haiku» — саме в цьому діапазоні, за оцінкою автора гайду, зараз лежить реалістичний максимум для десктопів і сучасних лаптопів з потужним GPU або великою unified memory.
Граничний розмір моделі диктує:
- відеопам’ять на Windows‑машинах;
- обсяг unified memory на нових Mac із чипами M‑серії.
Моделі, які повністю вміщуються у VRAM або у виділену частину unified memory, працюють відносно швидко. Якщо ж їх розмір перевищує доступний обсяг, «надлишок» іде в системну RAM або навіть на диск, і швидкість падає на порядки. Звідси практичне правило: має сенс триматися в межах розміру моделі, який комфортно входить у ваш VRAM із запасом.
На Mac можна, як правило, завантажити більшу модель завдяки єдиній пам’яті, але вона не завжди буде швидшою. На дискретному GPU Windows пропонує вищу пропускну здатність відеопам’яті, тож модель менша за обсягом може працювати швидше, ніж більша на Mac.
Усе це означає, що локальний workflow за замовчуванням не конкурує з топовими хмарними моделями. Він скоріше добирає все, що можна, на локальному рівні, залишаючи хмару лише для найскладніших задач.
«Завантажити модель» недостатньо: що таке справжній agentic workflow
Для локального AI‑кодингу саме по собі скачування моделі — лише перший крок. «Це одна справа — отримати локальну модель на свій комп’ютер. Інша — змусити її працювати всередині середовища розробки, щоб вона могла реально виконувати задачі».
Повноцінний agentic‑workflow, описаний у гіді, складається з трьох шарів.
По‑перше, самі моделі, які вміють робити різні речі. Невеликий, але дуже швидкий варіант використовується для автодоповнення: він має небагато параметрів, займає небагато пам’яті й миттєво відповідає на короткі промпти, які IDE генерує при наборі коду. Поруч працює основна, більша й більш здатна модель для діалогів, редагування файлів і роботи в агентному режимі.
По‑друге, менеджер локальних LLM. У цьому сценарії таку роль відіграє LM Studio. Він дозволяє не тільки завантажувати й тримати на диску різні варіанти моделей, а й тонко налаштовувати їх: виставляти довжину контексту, рівень GPU offload, обирати quantization. Важливий момент — підтримка tool‑use основною моделлю: без цього агент не зможе викликати інструменти IDE, створювати й змінювати файли, виконувати команди, а перетвориться на звичайний чат‑бот, що лише «пояснює код».
По‑третє, інтеграція з середовищем розробки. Саме тут локальний AI перетворюється на реальний робочий інструмент. Сучасна версія Visual Studio Code вміє підключатися до локальних моделей через кастомний endpoint, працюючи з ними так само, як із хмарними постачальниками. Запускаючи в LM Studio локальний сервер, розробник експонує свої моделі в межах машини, а VS Code бачить їх як стандартний endpoint для chat‑completions і агентного режиму.
Додатково окремий плагін у VS Code підхоплює локальну модель автодоповнення, щоб навіть inline‑підказки працювали повністю офлайн.
Як виглядає такий стек у щоденній роботі
Після того як моделі підібрано під апаратні можливості, а LM Studio та VS Code пов’язані, розробник отримує повністю автономне середовище. У ньому можна писати запити в чаті IDE, обирати режим — «agent», «plan» чи «edit» — та давати моделі завдання від створення проєкту до рефакторингу файлів.
Усе запускається на одній машині: LM Studio бере на себе підняття моделей і логування запитів, VS Code — інтерфейс і прив’язку до файлової системи. Кожен токен, що виходить із моделі, породжується локально — без сторонніх серверів, без затримок на мережу і без ризику витоку коду в хмару.
Результати, як визнає автор, «будуть різними… це не так добре, як Opus». Але саме тут і проявляється реальна ніша локального стеку. Для нескладних змін, написання невеликих функцій, невеликих агентних задач він виявляється цілком достатнім.
Власник сучасного ПК або Mac із потужним GPU може дійти до точки, коли більшість повсякденних операцій у коді закриває локальний агент. «До того моменту, як ви це налаштуєте, ви можете просто використовувати це постійно і звертатися до високорівневої моделі лише коли потрібно щось дуже складне».
Коли локальний AI реально виручає
Якщо розглядати цей підхід не як заміну, а як доповнення до хмарних моделей, його сильні сторони стають очевидними. Локальний стек стає базовим інструментом «на кожен день», тоді як хмарні опції — резервом для складних, критичних задач.
Особливо це помітно в сценаріях з обмеженою або відсутньою мережею й без доступу до платних API. «Результати будуть різними… це не так добре, як Opus… але якщо ви в літаку, без кредитів, робите менші правки функцій — це працює і працює досить добре».
Тут важить не абсолютна якість відповіді, а сам факт наявності «розумного асистента» прямо в офлайні. Можливість отримати автодоповнення, попросити модель швидко накинути структуру функції або пояснити шмат коду, не підключаючись до інтернету, виявляється практичною перевагою.
На іншому полюсі — питання продуктивності. Автор прямо зазначає, що в окремому матеріалі планує пройтися «по продуктивності цих локальних моделей і поговорити про це більш детально». Поки ж рекомендації зводяться до підбору розміру моделі під VRAM, використання агресивної quantization для прискорення роботи та тестування кількох варіантів, щоб знайти баланс між швидкістю та якістю.
Контроль, економія й обмеження: що дає локальний стек сьогодні
Повністю локальний agentic‑кодинг, побудований на зв’язці LM Studio та VS Code, демонструє, що автономний AI‑асистент для розробки більше не є екзотикою. Локальні моделі вже «стали неймовірно хорошими і відносно простими в запуску… ви можете робити повний локальний кодинг, без інтернету… без оплати за токени».
Втім, цей підхід вимагає:
- сучасного заліза з достатньою пам’яттю, щоб працювати в комфортному діапазоні моделей;
- готовності миритися з тим, що якість контенту не досягає рівня найпотужніших хмарних рішень;
- певної ручної роботи з налаштуваннями моделей, контексту й інтеграцій.
В обмін розробник отримує контроль над стеком, передбачувані витрати (фактично — лише електрика й амортизація заліза) та повну локальність даних. А хмара перетворюється з єдиного способу працювати з AI на опціональний інструмент «верхнього рівня» для окремих, дійсно складних задач.
Це не кінець хмарних LLM, але очевидний початок епохи, коли робоча станція розробника сама по собі стає достатньо потужною, щоб тягнути власного, повноцінного AI‑агента.