Локальні великі мовні моделі перестали бути екзотикою для ентузіастів з серверними фермами. Сучасний ноутбук уже здатен запускати досить потужні LLM, а завдяки таким інструментам, як Ollama та Zapier MCP, ці моделі можна перетворити на повноцінних агентів, що працюють з Google Calendar, Notion, рекламними кабінетами й іншими сервісами. У цьому матеріалі, спираючись на детальний туторіал з каналу Tech With Tim, розбираємося, як правильно обрати модель для Ollama, що реально потягне ваш комп’ютер, чому критично важлива підтримка tool calling і де проходить межа між «просто чатботом» та справжнім AI‑агентом.
Від LLM до агента: чому tool calling змінює все
Базова LLM — це, по суті, генератор тексту. Вона приймає текстовий запит і повертає текстову відповідь. У кращому разі — дуже розумну, структуровану й корисну, але все одно це лише текст. Вона не створює події в календарі, не оновлює базу в Notion і не запускає рекламні кампанії, доки не з’являється проміжний шар — інструменти, або tools.
Саме тут починається різниця між «великим мовним моделем» і «AI‑агентом». Агент — це система, яка не тільки генерує текст, а й здатна викликати зовнішні інструменти: API‑методи, інтеграції, сервіси. Для цього модель має вміти робити tool calling — спеціальний режим, коли вона не просто відповідає користувачу, а формує структурований запит до зовнішнього інструменту, отримує результат і вже на його основі продовжує діалог або виконує наступні дії.
Без підтримки tool calling локальна LLM, запущена через Ollama, залишиться лише приватним чатботом на вашому комп’ютері. Вона може допомогти з текстами, кодом чи поясненнями, але не зможе «вийти назовні» й працювати з вашими реальними даними та сервісами. Якщо ж модель підтримує tools, її можна під’єднати до Zapier MCP, який відкриває доступ до понад 8000 інтеграцій — від Google Calendar і Notion до маркетингових платформ. Тоді локальна LLM перетворюється на агента, що реально щось робить, а не лише радить.
Саме тому в демонстрації з Ollama використовується модель Qwen 3.5: вона прямо позначена як така, що підтримує tools, і це робить її придатною для агентної поведінки та інтеграцій.
Як апаратне забезпечення диктує вибір моделі: RAM, VRAM і реалістичні очікування
Найчастіша помилка новачків у локальних LLM — спроба одразу запустити найбільшу й «найрозумнішу» модель, яку тільки знаходять у бібліотеці Ollama. На практиці це швидко впирається в обмеження пам’яті та продуктивності.
Ключовий параметр — кількість параметрів моделі. У бібліотеці Qwen 3.5 можна побачити варіанти з різними розмірами: приблизно від 0,8B до 27B, 35B і аж до 122B параметрів. Чим більше параметрів, тим кращою зазвичай є якість відповіді, але тим вищі вимоги до пам’яті й тим повільніше працює модель.
У демонстрації автор спочатку завантажує Qwen 3.5 35B через команду ollama pull, і клієнт починає тягнути близько 23 ГБ даних. Уже на цьому етапі стає зрозуміло, що модель важка не лише на диску. Після запуску виявляється, що вона використовує приблизно 24 ГБ оперативної пам’яті, і на машині з 32 ГБ це відчутно: модель довго завантажується, відповіді з’являються повільно, а система в цілому стає менш чутливою.
Ще один варіант — Qwen 3.5 122B. Для нього вказано орієнтовне споживання близько 81 ГБ RAM. На ноутбуці з 32 ГБ таку модель можна теоретично завантажити у вигляді сильно квантованої версії або з частковим вивантаженням, але практично це означає крайні затримки, свопінг на диск і майже повну непридатність до реальної роботи. Автор прямо називає цей варіант непрактичним для 32‑гігабайтної машини.
У підсумку він переходить на Qwen 3.5 27B, яка виявляється кращим компромісом для MacBook з M2 Max і 32 ГБ уніфікованої пам’яті. Модель усе ще досить велика, щоб давати якісні відповіді, але не настільки важка, щоб «забити» всю систему. Це показовий кейс: навіть на відносно потужному ноутбуці не завжди варто гнатися за найбільшим числом параметрів.
Apple Silicon проти Windows і Linux: як по‑різному рахується пам’ять
Щоб правильно підібрати модель в Ollama, важливо розуміти, як саме ваш комп’ютер виділяє пам’ять під LLM. Тут є принципова різниця між новими Mac на Apple Silicon і типовими Windows чи Linux‑машинами.
На сучасних Mac з чипами M‑серії використовується уніфікована пам’ять. Це означає, що немає окремої RAM для процесора й окремої VRAM для відеокарти: є один спільний пул пам’яті, який використовують і CPU, і GPU. Якщо на такому Mac встановлено 32 ГБ, то саме з цих 32 ГБ виділяється місце під модель. У реальності безпечно орієнтуватися на 70–80% від загального обсягу, оскільки частину пам’яті забирає сама операційна система та інші програми.
У випадку Windows і більшості Linux‑систем ситуація інша. Тут зазвичай є окрема оперативна пам’ять (RAM) і окрема відеопам’ять (VRAM) на дискретній відеокарті. Локальні LLM, особливо при використанні GPU‑прискорення, працюють саме у VRAM. Наприклад, якщо у вас NVIDIA RTX 4090 з 24 ГБ VRAM, то саме ці 24 ГБ — реальна «стеля» для розміру моделі, яку можна ефективно запустити на GPU. RAM при цьому теж важлива, але основне обмеження — відеопам’ять.
На практиці це означає, що користувачам Mac простіше орієнтуватися: достатньо знати загальний обсяг уніфікованої пам’яті й співвіднести його з вимогами моделі. Користувачам Windows і Linux потрібно дивитися саме на характеристики відеокарти й обсяг VRAM. Якщо дискретної графіки немає, модель доведеться запускати на CPU, і тоді навіть відносно невеликі варіанти будуть працювати дуже повільно.
У туторіалі прямо зазначається: моделі можна запускати й на машинах без GPU, якщо є достатньо місця на диску для зберігання ваг. Але в такому режимі вони будуть «надзвичайно повільними». Це радше варіант для експериментів, ніж для щоденної продуктивної роботи.
Чому 9B — розумний мінімум, а «чим більше параметрів, тим краще» працює не завжди
Інтуїтивно здається, що найбільша модель завжди буде найкращою. У загальному випадку це правда: більше параметрів означає більше «місця» для збереження знань і складніших закономірностей, а отже, кращу якість відповідей. Але в локальному сценарії це правило впирається в апаратні обмеження й комфорт роботи.
У демонстрації автор прямо говорить: більші моделі зазвичай працюють краще, але вимагають більше RAM або VRAM. Якщо модель не поміщається в пам’ять повністю, система починає активно використовувати диск, і продуктивність падає до неприйнятного рівня. Навіть якщо модель формально запускається, час відповіді може обчислюватися десятками секунд або хвилинами, що робить її практично непридатною для інтерактивного використання.
Тому як практичну відправну точку рекомендується орієнтуватися на моделі приблизно з 9 мільярдами параметрів. Це не жорстке правило, але корисний орієнтир для більшості користувачів. Такі моделі зазвичай:
достатньо малі, щоб запускатися на сучасних ноутбуках і десктопах без критичного навантаження на пам’ять;
достатньо великі, щоб давати прийнятну якість відповідей у широкому спектрі завдань — від загального асистування до базового кодування.
У бібліотеці Qwen 3.5 є варіанти з різною кількістю параметрів, і саме 9B‑моделі виглядають як «золота середина» для тих, хто не має топового GPU чи 64–128 ГБ уніфікованої пам’яті. Якщо ж у вас потужніший комп’ютер, можна переходити до 27B або 35B, але важливо стежити за тим, як це впливає на швидкість відповіді й загальну стабільність системи.
Показовий момент у туторіалі — тестування Qwen 3.5 35B. Після завантаження моделі автор дає їй простий запит на кшталт «розкажи, в чому ти хороша» й спостерігає, як довго вона починає відповідати. Затримка виявляється відчутною, що й підштовхує до рішення перейти на легшу 27B‑версію. Це наочна демонстрація того, що «максимальний розмір» не завжди дорівнює «максимальній корисності».
Tool calling як критерій №1: чому не кожна модель в Ollama підходить для агентів
Навіть якщо ви підібрали модель, яка добре вписується в обмеження вашої пам’яті, це ще не гарантує, що її можна буде перетворити на агента. Для цього потрібна підтримка tool calling, і в бібліотеці Ollama це явно позначається.
У туторіалі показано, як при пошуку моделей, наприклад Llama 3, можна натрапити на варіанти, де ніде не згадується підтримка tools. Такі моделі чудово працюють як звичайні чатботи: вони приймають текст, повертають текст, можуть допомогти з поясненнями, ідеями, навіть кодом. Але вони не вміють формувати структуровані виклики інструментів, а отже, не можуть безпосередньо працювати з інтеграціями через Zapier MCP чи інші системи.
Автор прямо застерігає: деякі варіанти Llama 3 в Ollama не підтримують tool calling. Якщо завантажити одну з таких моделей, її можна буде використовувати лише як автономний чатбот, без можливості викликати зовнішні сервіси. Для сценарію, де локальна LLM має стати центром автоматизації, це критичне обмеження.
Тому при виборі моделі в бібліотеці Ollama потрібно не просто дивитися на назву й розмір, а уважно перевіряти, чи є в описі згадка про tools або tool calling. У випадку Qwen 3.5 така підтримка є, і саме тому ця модель обрана як основа для побудови локального агента з інтеграціями.
Це правило універсальне: якщо ваша мета — не просто «локальний ChatGPT», а система, яка може створювати події в календарі, оновлювати записи в Notion чи працювати з іншими сервісами, то підтримка tools стає обов’язковою вимогою до моделі. Без цього будь-які подальші налаштування MCP, мостів і інтеграцій просто не матимуть сенсу.
Практичний досвід з Qwen 3.5 в Ollama: від 35B до 27B
Демонстрація з Qwen 3.5 добре ілюструє, як теоретичні міркування про пам’ять і параметри стикаються з реальністю конкретної машини.
Початковий план — використати Qwen 3.5 35B. Модель підтримує tool calling, відносно нова, оновлена всього за кілька тижнів до запису, і виглядає привабливо з точки зору якості. Команда ollama pull qwen3.5:35b завантажує близько 23 ГБ ваг. Після цього модель запускається через ollama run, і починається тестування.
На MacBook з M2 Max і 32 ГБ уніфікованої пам’яті 35B‑варіант виявляється важким: завантаження в пам’ять займає помітний час, а відповіді моделі приходять повільно. Приблизне споживання RAM — близько 24 ГБ, що залишає небагато простору для самої системи й інших процесів. Формально модель працює, але практично — надто повільно для комфортної взаємодії, особливо якщо планується тривала робота агента з інтеграціями.
Після цього ухвалюється рішення перейти на Qwen 3.5 27B. Це все ще велика й потужна модель, але трохи легша за 35B‑версію. На тій самій машині вона дає кращий баланс між якістю й швидкістю. Важливо, що при цьому зберігається ключова властивість — підтримка tool calling, тож модель як і раніше придатна для побудови агента.
Цей кейс добре показує, як варто підходити до вибору моделі в Ollama:
почати з розуміння апаратних обмежень — обсягу RAM або VRAM;
вибрати модель, що підтримує tools, якщо потрібні інтеграції;
орієнтуватися на 9B як базовий рівень, а далі експериментувати з більшими варіантами, спостерігаючи за швидкістю й стабільністю;
не боятися відмовитися від надто великої моделі, якщо вона виявляється повільною, навіть якщо на папері виглядає привабливо.
Висновок: локальні LLM — це не тільки про «безкоштовно», а й про грамотний вибір
Запустити локальну LLM сьогодні технічно нескладно: достатньо встановити Ollama, відкрити термінал і виконати кілька команд. Справжня складність починається тоді, коли потрібно перетворити цю модель на корисний інструмент — агента, який працює з реальними сервісами, і при цьому не вбиває ваш комп’ютер.
Звідси випливають кілька ключових висновків.
По‑перше, підтримка tool calling — не опція, а обов’язкова умова для агентної поведінки. Моделі без tools залишаються лише чатботами, навіть якщо вони дуже великі й «розумні».
По‑друге, апаратні обмеження важать не менше, ніж якість моделі. На Mac з уніфікованою пам’яттю потрібно дивитися на загальний обсяг RAM, на Windows і Linux — на VRAM відеокарти. Моделі можна запускати й на CPU‑only машинах, але вони будуть надзвичайно повільними.
По‑третє, орієнтир на 9B параметрів як базовий рівень для більшості користувачів виглядає практичним компромісом між якістю й продуктивністю. Більші моделі, на кшталт 27B чи 35B, мають сенс лише тоді, коли апаратне забезпечення дозволяє працювати з ними без критичних затримок.
І нарешті, вибір конкретної моделі — це завжди баланс. Приклад з Qwen 3.5 показує, що навіть на потужному 32‑гігабайтному MacBook доводиться відмовлятися від 35B‑варіанту на користь 27B заради кращої швидкості. У світі локальних LLM «найбільша» не завжди означає «найкраща для вас».
Джерело
How to Run LLMs Locally + Connect to Everything – Full Tutorial (Ollama)