Технічний контекст
Я зацікавився дуже практичним питанням: чи можна зібрати локального DM-асистента на Gemma 4, щоб він і квести генерував, і пам'ятав довгу сесію, і не вимагав хмари. Для такого AI implementation відповідь у мене проста: так, але не через лобове завантаження всієї історії в контекст.
З того, що я бачу в бенчмарках та обговореннях, Gemma 4 26B-A4B і 31B вже працюють у llama.cpp на RTX 3050/3060, особливо якщо квантувати. Але магії немає: навіть якщо у MoE активно лише близько 4B параметрів на токен, у пам'яті модель все одно важка, а довгий контекст починає душити залізо.
На 3060 з 12 GB я б дивився в бік сильно стиснутої 26B-A4B або взагалі менших E2B/E4B, якщо потрібен стабільний локальний сценарій. На 3050 з 8 GB вже доведеться дуже обережно різати очікування: швидкість падає, частина йде в RAM, а при довгих запитах починаються ті самі зависання, на які й скаржаться користувачі.
І ось тут у мене не сходиться популярна ідея "давайте просто дамо 128K або 256K контексту". На папері це красиво. У реальній сесії по DnD або будь-якій довгій грі модель починає або забувати важливе, або витрачати занадто багато обчислень на повторне пережовування всієї історії.
Я б робив пам'ять простішою. Не повноцінний агентний пошук на кожен чих, а зовнішню структуру під конкретний юзкейс: Markdown-файли, SQLite, append-only лог подій, плюс короткі самарі після сесії. Моделі на вхід я б давав не весь світ, а 5-15 фактів про персонажів, поточну арку, активні квести та останні зміни стану.
Якщо потрібен пошук, то локальний FAISS або HNSW поверх нотаток вже вирішує половину проблеми. Якщо потрібен зовсім бюджетний режим, то навіть без класичного RAG можна жити на правилах інжекту: хто важливий, що змінилося, що не можна ламати в сюжеті.
Що це змінює для бізнесу та автоматизації
Головний висновок у мене такий: агентний пошук розумніший, але він не завжди виправданий на слабкому залізі. Для локальних продуктів та AI automation на бюджетних ПК часто виграє більш "тупа", зате передбачувана архітектура пам'яті.
Виграють ті, хто проєктує асистента під завдання, а не під хайп навколо довгого контексту. Програють команди, які намагаються замінити архітектуру одним великим вікном токенів.
Я такі компроміси регулярно збираю і для клієнтів також: де вистачить структурованої пам'яті, де потрібен RAG, а де вже дійсно варто будувати AI integration з агентами та інструментами. Якщо у вас схожа історія, і локальний асистент повинен працювати швидко, стабільно і без хмарної залежності, давайте розкладемо ваш сценарій по шарах і в Nahornyi AI Lab спокійно зберемо AI solution development без зайвих обчислень і декоративної складності.