Технічний контекст
Я зачепився за цифру 115 tok/sec не через гарний скріншот, а тому, що це вже схоже на нормальну робочу швидкість для AI automation на Mac, а не на лабораторний атракціон. Йдеться про gemma-4-26B-A4B-it-mlx-lm-4bit, тобто 26B MoE-модель, де на токен активні приблизно 4B параметрів.
Це важливий нюанс. На папері модель велика, але фактично навантаження на інференс помітно менше, ніж у щільної 26B або 30B-моделі. Саме тому зв'язка Gemma 4 + MLX на Apple Silicon зараз виглядає не як компроміс, а як цілком практична AI integration для локальних сценаріїв.
Офіційного бенчмарку від Google саме на цей сетап я не бачив. Джерело тут, по суті, ком'юніті: MLX-LM, 4-бітна збірка під Apple, оптимізації на кшталт TurboQuant та виміри від людей, які запускають це на M-серії вживу. Важлива частина новини в тому, що 115 tok/sec помітно вище того, що багато хто раніше бачив через недосконалі пайплайни або fallback-режими.
І ось тут я б не змішував усе в одну купу. Ollama, llama.cpp, "сирий" MLX-LM, довжина контексту, prefill та decode дають дуже різні цифри. Якщо хтось бачив 2 tok/sec на 26B MoE і вирішив, що модель «не тягне локально», цей бенчмарк якраз показує протилежне: проблема часто була не в моделі, а в стеку.
Ще один практичний момент: 4-бітний MLX-варіант вміщується приблизно в 14 ГБ, але для нормальної роботи все одно потрібен запас unified memory. На 24 ГБ вже можна комфортно працювати, а на старших M-чіпах це перетворюється на справді зручний локальний інференс без хмари, з хорошим контекстом і без вічного очікування відповіді.
Що це змінює для бізнесу та автоматизації
Для мене висновок простий: локальні агенти на Mac перестають бути іграшкою. Якщо модель реально тримає такий decode, я вже можу будувати приватні пайплайни для документів, підтримки, внутрішнього пошуку та аналітики без обов'язкового надсилання даних назовні.
Виграють команди, яким важливі швидкість, приватність та передбачувана собівартість. Програють насамперед хмарні сценарії, де маленькі запити обробляють через дорогий зовнішній API просто за інерцією.
Але тут є нюанс, який я регулярно бачу в клієнтських завданнях: сам по собі швидкий бенчмарк ще не означає гарну систему. Потрібні нормальна AI architecture, маршрутизація завдань, контроль контексту, кешування та розуміння, де локальна модель сильна, а де краще підключити зовнішній сервіс. Ми в Nahornyi AI Lab якраз створюємо такі системи під реальні процеси, а не під красиві демо.
Якщо у вас вже назріла AI implementation без хмарної залежності, я б подивився на ваш стек тверезо: що можна перенести локально, де скоротити затримки і як з цього зібрати робочу автоматизацію. У Nahornyi AI Lab я зазвичай починаю саме з цього, тому що Вадим Нагорний не любить продавати магію там, де бізнесу потрібен просто надійний результат.