Після розмов в попередній статті про те, що таке локальний AI і де він має сенс, логічно перейти до практики — не в теорії, а в реальних умовах. У нас була цілком прикладна задача: потрібен був інструмент для внутрішньої роботи з текстами й кодом, без передачі даних назовні та з передбачуваними витратами.
Першу версію ми піднімали в хмарі. Формально все працювало, але досить швидко вилізли обмеження: моделі вимагали багато оперативної памʼяті, навантаження було нерівномірним, а ресурси «зʼїдалися» значно швидше, ніж планувалося. Місячний бюджет, який виглядав розумним на папері, закінчився за два дні реальної роботи. Після цього стало зрозуміло, що для постійного використання такий підхід не масштабується ані фінансово, ані організаційно.
Саме в цей момент зʼявився інтерес до локального запуску — не як експерименту, а як робочого інструмента. Далі має сенс дивитися не на абстрактні «можливості AI», а на конкретне залізо й сценарії. Як поводиться базовий Mac mini з Apple Silicon, коли на ньому постійно працює локальна модель. Де проходить межа по оперативній памʼяті та що починає відчувати користувач у повсякденній роботі. І що змінюється, коли замість одного компʼютера зʼявляється кілька Mac Studio, які працюють як єдине рішення для невеликої команди.
Усе це варто розглядати без гонитви за цифрами в бенчмарках — через призму реальних задач: нотатки, підготовка листів, робота з кодом, внутрішній чат. Саме в таких сценаріях найкраще видно не тільки можливості, а й обмеження локального AI на Mac.
Базовий Mac mini M4
Я починав з Mac mini M4 не тому, що це «мінімально можливе рішення», а тому що це був найбільш приземлений варіант для перевірки ідеї. Хотілося зрозуміти, чи локальний AI взагалі вписується в робочий день, а не зібрати ще один тестовий стенд. Основним інструментом став Ollama — без зайвих налаштувань, з простим керуванням моделями і зрозумілою поведінкою в системі.
Першими моделями були Llama 3.2 3B і Mistral 7B. Почав саме з них, бо вони швидко стартують, не вимагають екзотичних конфігурацій і одразу показують, чи є сенс рухатися далі. Трохи пізніше додав Llama 3.2 Vision, коли зʼявилась потреба працювати з фрагментами скріншотів і документацією у вигляді PDF, а не тільки з текстом.
Перший тиждень використання був доволі показовим. Основні задачі — підготовка листів, чернетки технічних відповідей клієнтам і допомога з кодом, коли потрібно швидко розібрати чужий фрагмент або структуру конфігурації. Найбільше здивувала не швидкість як така, а відсутність відчуття, що компʼютер «напружується». Якщо змиритись з тим що навіть найпростіші моделі займали половину оперативної пам’яті – в іншому Mac mini залишався тихим. Система поводилася так, ніби нічого особливого не відбувається, а модель просто завжди під рукою. При цьому відповіді від Mistral 7B йшли в темпі живого діалогу, без пауз, які ламають хід думок.
Чесно кажучи, спочатку я очікував більшого. Було відчуття, що Mac mini зможе закрити майже всі сценарії, включно з важкими моделями і постійним навантаженням протягом дня. Через кілька днів стало зрозуміло, що його реальна роль інша. Це не універсальний сервер і не заміна хмарі у всьому. Це стабільна, передбачувана точка входу, яка добре працює з невеликими й середніми моделями, але чесно показує межі по памʼяті та масштабуванню.
У базових конфігураціях з 16 або 24 гігабайтами уніфікованої памʼяті Mac mini дозволяє тримати модель у RAM і працювати без постійних підвантажень. Саме це робить його придатним для щоденного використання, а не для демонстрацій. Навіть мультимодальні сценарії з Llama Vision залишаються комфортними, якщо не намагатися вичавити з машини більше, ніж вона здатна дати.
Версії Mac mini M4 Pro з більшим обсягом памʼяті відкривають додаткові можливості, але принципово не змінюють роль пристрою. Так, у стисненому вигляді можна запускати значно важчі моделі для аналізу текстів або коду, але швидкість там вже не про інтерактивність. Це радше асинхронна робота: запустив задачу, отримав результат, пішов далі.
У підсумку Mac mini M4 виявився не «маленьким сервером», а зручним робочим інструментом. Він добре підходить для персонального використання або невеликої команди, допомагає зрозуміти власні сценарії й обмеження локального AI і не вимагає складної інфраструктури. Це та точка, з якої зручно починати — і з якої стає зрозуміло, коли і навіщо рухатися далі.
Mac Studio як сервер
Mac Studio зʼявився не у нас в офісі. Його поставив клієнт і давній знайомий, з яким ми давно працюємо як підрядники по MDM і внутрішній macOS-інфраструктурі. Спочатку це виглядало як логічне продовження історії з Mac mini: більше памʼяті, більше запасу по потужності, менше компромісів. Але досить швидко стало зрозуміло, що роль цієї машини інша.
Переломний момент був доволі буденним. Перший спільний запит відразу від двох людей, а потім фраза в чаті: «А чого сьогодні відповідає повільніше?». У цей момент Mac Studio перестав бути “його компʼютером”. Він став чимось, до чого підключаються. Машиною, яку не вимикають на ніч, і до якої звертаються як до сервісу, а не як до робочого столу.
Точка входу була максимально простою. Внутрішній веб-інтерфейс за локальним URL: звичайний чат, історія запитів, відповіді, які зʼявляються рядок за рядком. Людина відкриває браузер, бачить знайоме поле вводу, попередні діалоги і працює, не думаючи, де фізично стоїть машина і що там під капотом. Ніяких клієнтів, ніяких налаштувань — просто сторінка, яка завжди доступна в офісній мережі.
Сам Mac Studio з M3 Ultra в цій ролі поводився дуже передбачувано. Конфігурація з великим обсягом уніфікованої памʼяті дозволяла тримати моделі в RAM і не ганяти їх туди-сюди. Для щоденних задач 7B і 13B-моделі працювали в темпі живого діалогу, а 70B у стисненому вигляді вже ставали реальним інструментом для аналізу текстів і коду. Важливо було навіть не це, а те, що відповіді приходили за час, який не ламав робочий ритм. Запит пішов — за кілька секунд є результат.
Десь на цьому етапі я вперше подумав про AI не як про сервіс, а як про частину інфраструктури. Не «ще один тул», а щось на кшталт внутрішнього сервера: він просто має працювати, бути доступним і не вимагати постійної уваги. Mac Studio добре ліг у цю роль — тихий, компактний, без окремої серверної і з поведінкою, яку легко пояснити замовнику без технічних лекцій.
Для офісу з кількома активними користувачами така конфігурація виявилася дуже влучною. Машина стоїть, працює цілий день, моделі живуть у памʼяті, а люди швидко звикають, що AI — це не “запусти щось у себе”, а “зайди і скористайся”.
Кластери до macOS Tahoe
Коли одного Mac Studio стало замало, усе пішло по накатаній. Додали ще один, потім ще. Запитів більшало, задачі ускладнювалися, і локальний AI переставав поміщатися в рамки одного сервера. Формально це виглядало логічно: більше машин — більше ресурсу.
Але саме тут почало зʼявлятися перше тертя. Не на рівні технологій, а на рівні відчуттів. Кожна нова машина додавала не тільки потужність, а й запитання: куди пішов запит, чому цей відповів швидше, а той — ні, і чому сьогодні вся система відчувається “трохи ватною”. Масштабування переставало бути інтуїтивним.
Кластери будувалися приземлено: 10-гігабітна мережа, кілька Mac Studio, на кожному свій інстанс, зверху балансування. Воно працювало, але з ростом кількості вузлів починало вимагати дедалі більше уваги. Чотири машини ще давали відчутний приріст, пʼята і шоста — вже значно менший. Зʼявлялося відчуття, що ти знову повертаєшся до класичної серверної історії, від якої намагався втекти.
Thunderbolt-зʼєднання виглядало привабливо на папері, але в реальності не змінювало суті. Так, трохи краща пропускна здатність, трохи менші затримки, але все одно це був мережевий обмін, зі всіма його обмеженнями. Дані не ставали “спільними”, вони просто швидше передавалися.
У якийсь момент виникло просте питання: а чи варта ця складність того? Не з точки зору можливостей, а з точки зору щоденного супроводу. Саме тоді стало зрозуміло, що цей підхід має стелю, і без змін на рівні самої системи він далі масштабуватися не буде. І це відчуття зʼявилося не з бенчмарків, а з щоденної роботи і дрібних незручностей, які накопичуються швидше, ніж здається на старті.
Після Tahoe 26.2
Після виходу macOS Tahoe 26.2 відчуття від локальних кластерів на Mac помітно змінилося. Масштабування перестало сприйматися як щось крихке або умовне. Система почала поводитися цілісно, без постійних дрібних ознак того, що вона зібрана з окремих машин, які лише намагаються працювати разом.
Найважливіше тут — як саме машини взаємодіють між собою. До 26.2 обмін даними завжди відчувався як мережевий процес, навіть якщо фізично Mac стояли поруч і були зʼєднані швидким каналом. Дані проходили через звичні шари системи, навантажували процесор і додавали затримки, які накопичувалися зі зростанням кількості вузлів. Після появи RDMA поверх Thunderbolt 5 ця поведінка змінилася. Доступ до памʼяті іншої машини став прямим, без проміжних копій і зайвих переходів.
У повсякденній роботі це відчувається досить швидко. Коли до кластера додається ще один Mac Studio, система реагує передбачувано. Приріст продуктивності зʼявляється одразу і зберігається під навантаженням. Навіть при роботі з великими моделями темп генерації залишається рівним, без раптових пауз або “хвиль”, які раніше виникали під час обміну даними між машинами.
Змінюється і загальне враження від використання. Кластер більше не вимагає постійної уваги. Люди просто відкривають звичний інтерфейс, надсилають запит і отримують відповідь у зрозумілий час. Зникає потреба замислюватися, на якій саме машині зараз виконується задача і що відбувається всередині. Система починає сприйматися як стабільний фоновий елемент, до якого звикаєш так само, як до внутрішнього сервера або сховища.
Разом із цим поступово проявляються й практичні рамки такого підходу. Кілька Mac Studio добре працюють у звʼязці, але зі зростанням їхньої кількості починають грати роль фізичні обмеження. Довжина Thunderbolt-ланцюжків, розміщення машин, теплове навантаження, споживання енергії — усе це стає частиною щоденної реальності. Такі речі не заважають роботі напряму, але визначають розумний масштаб системи.
У підсумку після Tahoe 26.2 локальні кластери на Mac сприймаються як завершене рішення у своєму класі. Це компактні системи з кількох машин, які добре підходять для офісного середовища і постійного використання. Вони не потребують складної інфраструктури і не вимагають постійних компромісів у повсякденній роботі. Саме в цьому форматі цей підхід починає виглядати по-справжньому доречним.
Підсумок: як це виглядає в реальній роботі
Якщо дивитися на локальний AI без теорії й ентузіазму, усе зводиться до кількох дуже приземлених сценаріїв. Різниця між ними не в “рівні технологій”, а в тому, хто і як цим користується щодня.
Базовий Mac mini або iMac — це персональний інструмент. У такому форматі локальний AI працює як розширення робочого столу. Його використовують для коротких задач: швидко підсумувати лист, переформулювати текст, підготувати чернетку відповіді, перевірити фрагмент коду або звести кілька абзаців у зрозумілий конспект. Модель живе поруч із основними програмами, ділить ресурси з браузером і поштою, і це відчувається. Тут не чекають миттєвої реакції на складні запити й не намагаються проганяти через модель великі масиви даних. Це робочий помічник, який економить час у дрібних, але регулярних задачах.
Трохи інша картина виникає, коли зʼявляється Mac Studio. У цей момент локальний AI перестає бути “моїм” і стає спільним. Для користувача це виглядає просто: внутрішній веб-інтерфейс або клієнт із чатом, історією запитів і відповідями. Людина не думає про залізо, памʼять або те, скільки машин зараз працює. Вона просто звертається до системи, як до будь-якого іншого внутрішнього сервісу. У такому форматі AI вже беруть для більших текстів, аналізу документів, роботи з кодом або підготовки внутрішніх матеріалів для команди.
Кластери з кількох Mac Studio зʼявляються там, де навантаження стає постійним. Після Tahoe 26.2 і появи RDMA поверх Thunderbolt 5 такі системи перестали вимагати постійної уваги. До шести машин у звʼязці — це вже відчутний робочий інструмент із передбачуваною поведінкою. Користувачі бачать лише те, що система стабільно відповідає, навіть коли з нею одночасно працює кілька людей. Для невеликої команди цього масштабу зазвичай достатньо.
Далі починається зона інших рішень. Якщо потрібні великі мультимодальні моделі, довгі контексти на десятки тисяч токенів або стабільна робота для десятків користувачів одночасно, локальний Mac-кластер перестає бути раціональним вибором. У таких випадках або переходять на платні плани хмарних сервісів на кшталт Gemini чи ChatGPT, або орендують серверні кластери з відповідною інфраструктурою. Це інший клас задач і інші бюджети.
У підсумку локальний AI на Mac добре працює там, де важливі контроль, передбачуваність і відсутність зайвих залежностей. Він не замінює все і не намагається це робити. Але в межах своїх сценаріїв — від одного Mac mini до кількох Mac Studio — це спокійний, зрозумілий інструмент, який просто вбудовується в робочий день і не потребує окремого ставлення. Саме в цьому його практична цінність.
