Канал Tech With Tim відомий своїми прикладними розборами інструментів для розробників. В одному з нових випусків автор показує, як побудувати повністю локальний AI‑кодинг‑стек без хмари, з фокусом на LM Studio як центрі керування моделями. Нижче — конденсований практичний гайд по тій частині сетапу, яка стосується саме LM Studio: від вибору моделей родини Gwen до тестування швидкості, контексту, GPU offload і запуску локального сервера.
Чому саме LM Studio: більше контролю, ніж у «простих» лаунчерів
LM Studio у цьому підході виступає ядром локальної AI‑інфраструктури. Це не просто лаунчер моделей, а інструмент, який «дозволяє завантажувати і керувати локальними моделями з більшою точністю, ніж щось на кшталт O‑Lama».
Інтерфейс поділений на три основні зони:
- Chat — для безпосередньої роботи з моделлю в діалоговому режимі.
- Developer — для запуску локального сервера й перегляду логів запитів.
- Models / «робот» — для пошуку, вибору, завантаження і керування LLM.
Саме цей третій розділ стає ключовим, коли мова йде не лише про «запустити модель», а про точне підбирання варіантів за параметрами, quantization, активними параметрами та можливістю tool use. Далі навколо цього й будується вся логіка локального AI‑кодингу.
Дві моделі, два сценарії: швидкий autocomplete і «важкий» агент
Вся схема локального AI‑кодингу в цьому сетапі спирається на просту, але важливу ідею: використовувати не одну, а дві моделі, кожну під свою роль.
Формула виглядає так: «Зазвичай ми будемо використовувати дві моделі… одну дуже маленьку, швидку для autocomplete, і одну значно більшу, більш здатну — для чату, редагування, agentic‑режиму».
Перша модель — це «мотор» автодоповнення, який повинен відповідати миттєво. Тут жорстко пріоритизується швидкість, навіть ціною нижчої загальної потужності.
Друга — основний «мозок» для:
- чат‑взаємодії з кодом,
- складних рефакторингів,
- виконання планів у agentic‑режимі,
- створення й редагування файлів через інструменти.
Поділ ролей дозволяє на тому самому залізі одночасно мати й комфортний live‑autocomplete, і досить потужний локальний агент, який вже не виглядає як «обрізана» версія хмарного LLM.
Autocomplete‑модель: чому ставка робиться на Gwen 2.5 coder 1.5B
Для ролі автодоповнення в цій конфігурації обрана одна «робоча конячка»: «Для більшості з нас ми просто будемо використовувати Gwen 2.5 coder з 1.5B параметрів як autocomplete‑модель».
Логіка тут утилітарна:
- 1.5 млрд параметрів — достатньо для адекватних підказок коду.
- Модель дуже маленька за розміром (сотні мегабайт), тож запускається практично на будь-якій сучасній машині.
- Навіть без окремої відеокарти її можна використовувати, хоча тоді вона буде помітно повільнішою.
В LM Studio цю модель можна знайти за назвою Gwen 2.5 coder 1.5B (instruct‑варіант). Автор сетапу просто бере найбільший quantized‑варіант, який «все одно дріб’язковий» для його заліза, але доступні й значно компактніші збірки близько 900 МБ.
Ключова вимога для autocomplete‑моделі проста: мала вага і максимальна швидкість токенів за секунду. Усе інше — другорядне.
Головна модель: без tool use локальний агент «осліплий»
Як тільки мова заходить про основну чат‑модель, вимоги до неї різко змінюються. Тут на перший план виходить не тільки якість коду, а насамперед наявність підтримки інструментів:
«Для основної чат/редагувальної моделі їй потрібен tool use… якщо немає tool use, вона не зможе викликати інструменти, створювати файли, реально редагувати код».
Це критичний момент: без tool use модель може лише «радити» код у відповідях, але не здатна:
- запускати інструменти IDE,
- створювати/переписувати файли,
- виконувати агентні плани всередині редактора.
Фактично це перетворює її на звичайний AI‑чат, а не повноцінного код‑агента. Тому при виборі моделі в LM Studio автор перш за все фільтрує кандидати за наявністю tool use, а вже потім дивиться на розмір, quantization і швидкість.
Вибір Gwen 3.6 35B: баланс потужності, ваги й швидкості
На високопродуктивній машині з великим об’ємом пам’яті (M‑серія Mac із 64 ГБ unified memory) робиться ставка на середній за локальними мірками «важковаговик»:
«Я вирішив взяти Gwen 3.6 35B… 22 GB у Q4… легко влізає в мою пам’ять і працює відносно швидко».
Важливі деталі цього вибору:
- Модель має 35 млрд параметрів, тобто помітно вища за «мінімальний» рівень для локальних код‑LLM.
- Використовується Q4‑quantization, що зменшує вагу збірки до приблизно 22 ГБ — цього достатньо, аби вона «комфортно» вміщувалась у доступну пам’ять.
- Tool use увімкнено, отже модель придатна для agentic‑кодингу, редагування файлів і роботи з інструментами.
Автор прямо протиставляє таку конфігурацію спробам запустити максимально велику, але повільну модель: менша quantized‑збірка із хорошим балансом параметрів дає кращий сукупний досвід, ніж «монстр», який ледь ворушиться.
A3B та «активні параметри»: як змусити великі моделі працювати на слабшому GPU
Окремий акцент зроблено на варіантах моделей із позначенням A3B, A6B тощо. Вони особливо цікаві тим, хто має обмежене залізо, але хоче підняти відносно великі LLM:
«Активні параметри A3B означають, що на вашій відеокарті реально працює менше параметрів, ніж повний розмір моделі… це дозволяє запускати більші моделі на слабшому залізі».
Суть у тому, що:
- повний розмір моделі може бути, скажімо, 14B,
- але активних параметрів (A3B) — тільки 3B, які фактично обчислюються на GPU,
- решта структури моделі оптимізована таким чином, щоб не вимагати такого ж обсягу ресурсів, як класична «повноактивна» версія.
Результат — можливість запускати збірки з формально великою кількістю параметрів на відеокартах середнього класу, не впираючись у жорсткі обмеження VRAM.
У практичній частині розбору якраз рекомендується Gwen 3.6 14B із позначкою A3B як добрий компроміс для машин із орієнтовно 16 ГБ VRAM: модель відносно велика за потужністю, але все ще «підйомна» для масових конфігурацій.
Тестування моделі в LM Studio: GPU offload, контекст і швидкість
Перед тим як інтегрувати модель у редактор, автор пропонує обов’язково пройти «обкатку» безпосередньо в LM Studio. Цей етап складається з кількох ключових налаштувань.
По‑перше, GPU offload: «Коли ви тестуєте модель у чаті LM Studio… просто переконайтесь, що GPU offload максимально високий». Це гарантує, що максимальний об’єм моделі працює саме на відеокарті, а не в системній пам’яті чи, ще гірше, на диску. Зменшення offload’у миттєво вбиває швидкість.
По‑друге, довжина контексту. У вікні налаштувань моделі LM Studio показує:
- повну довжину контексту, яку підтримує модель (наприклад, до 262 тисяч токенів),
- оцінку використання пам’яті при різних значеннях контексту.
Рекомендація проста: «налаштуйте довжину контексту так, щоб вона влазила у вашу пам’ять». Тобто:
- орієнтуватися на свій VRAM або unified memory,
- дивитися у верхній панелі LM Studio, скільки пам’яті займе модель із поточним значенням контексту,
- не гнатися за максимальними цифрами, якщо це призведе до виходу за межі доступної пам’яті та падіння швидкості.
По‑третє, практичний тест у чаті: після натискання Load модель стартує, і можна запустити простий діалог, щоби подивитися:
- чи стабільно вона відповідає,
- скільки токенів за секунду видає,
- чи не падає через брак пам’яті.
На потужній машині у прикладі швидкість трималася на рівні близько сотні токенів за секунду — цього достатньо, щоб досвід роботи не відчувався «затягнутим».
Developer‑режим: локальний сервер як місток до редактора
Останній крок усередині LM Studio — це не просто «запустити модель», а підготувати її до взаємодії з іншими інструментами через API.
У вкладці Developer запускається локальний сервер. Далі потрібно:
- увімкнути сервер,
- по черзі завантажити в нього обидві моделі — основну чат/agentic‑модель та autocomplete‑модель,
- ще раз відкоригувати налаштування GPU offload і контексту для кожної, виходячи з доступної пам’яті.
Після завантаження обидві моделі стають доступними через HTTP‑ендпоінт LM Studio. Контролювати їхню роботу можна через developer‑логи: там видно всі запити з редактора, швидкість генерації, можливі помилки.
Усе це — підготовчий етап до інтеграції з редактором коду. Далі вже інші інструменти (у розборі використовується VS Code) просто бачать локальний endpoint як «звичайний» LLM‑API, але фізично вся інференція відбувається на вашій машині.
Підсумок
Якщо відкинути маркетингові обіцянки навколо «локального ШІ», практична реальність виявляється досить структурованою. У запропонованій конфігурації LM Studio стає центральною керуючою консоллю: тут обираються моделі (передусім родина Gwen), налаштовуються quantization, активні параметри й tool use, тестуються швидкість і контекст, а потім усе це виводиться через локальний сервер до редактора.
Схема «мала Gwen 2.5 coder 1.5B для autocomplete + більша Gwen 3.6 з tool use як основний агент» показує, що локальний AI‑кодинг без хмари вже не виглядає екзотикою. За умови уважного налаштування VRAM, GPU offload і довжини контексту такі моделі стають реальним робочим інструментом, а не просто техно‑демо.