Локальные ассистенты и тяжелые MoE

За период выделяются два прикладных сюжета. Первый — как собрать локального AI-ассистента с управляемой персоной и долговременной памятью, и на его базе автоматизировать персональный CRM. Второй — как оценивать и планировать внедрение тяжёлой MoE-модели (Qwen 3.5), если нужны длинный контекст и «нативная» мультимодальность.

Как я использую OpenClaw каждый день (21 сценарий)

Для кого: CPO, Product Manager, Solo-Dev, Productivity

Конфигурация ассистента через 2 файла. OpenClaw настраивается через identity.md (базовая «идентичность») и soul.md (правила поведения и коммуникации), где можно задавать разные стили под разные каналы, чтобы ассистент не писал одинаково в личном чате и в Slack, который читают коллеги. schedule01:22

• Основные конфиги: identity.md, soul.md.
• В soul.md: параметры стиля ответа (формальность, лаконичность/подробность) и режимы по контексту (личный vs Slack).

Память: daily notes → distill → RAG. Память ведётся локально: диалоги складываются в ежедневные markdown-заметки, затем предпочтения и знания агрегируются в отдельный файл, и всё векторизуется для семантического поиска (RAG) по истории. schedule02:15

• Формат хранения: локальные markdown-файлы (daily notes) в папке memory.
• Агрегация: «дистилляция» в memory.md.
• Использование: ассистент читает память и обновляет identity на её основе.
• Поиск: векторизация файлов для RAG/семантического поиска по прошлым диалогам.

Персональный CRM: ingestion → очистка → отбор LLM → локальная БД → Q&A. Автор описывает CRM-пайплайн, который забирает данные из Gmail/календаря/Fathom, чистит входящий поток от «шума» (рассылки и холодные письма), затем LLM решает, какие диалоги/контакты сохранять, при необходимости делает ресёрч по контакту и сохраняет всё в локальную базу; дальше по базе можно задавать вопросы на естественном языке. schedule03:57

• Источники данных: Gmail, calendar, Fathom.
• Очистка noise: newsletters, cold pitches.
• LLM-логика: квалификация «что сохранять» + research по контакту при необходимости.
• Хранилище: локальная БД (упомянута вектор-колонка; детали обрываются).
• Масштаб: упомянуто 371 контакт.
• Примеры запросов: «когда последний раз общались», «что обсуждали», «кто последний в компании X».

Qwen 3.5 — следующая NEXT-модель

Для кого: CPO, Solo-Dev, Productivity

MoE-параметры: total vs active и число экспертов. Qwen 3.5 описана как Mixture-of-Experts: 397B параметров всего при 17B активных, с ростом числа экспертов до 512 (для сравнения: у Qwen 3 — 235B total, 22B active, 128 experts). Практика выбора MoE: смотреть не только на total params, но и на active params и количество экспертов. schedule01:12

• Qwen 3.5: 397B total, 17B active, 512 experts.
• Qwen 3 (крупнейшая публичная): 235B total, 22B active, 128 experts.

Локальный запуск: модель тяжёлая по RAM. Автор считает модель недружелюбной к локальному инференсу: даже в квантизированном виде ожидается порядка 256 GB RAM, возможно 512 GB, при этом для компаний с GPU-нодой возможен полностью автономный деплой с качеством, близким к проприетарным моделям без «триллионных» размеров. schedule02:37

• Оценка ресурсов (даже quantized): ~256 GB RAM (возможно 512 GB).
• Вывод по внедрению: Solo-Dev — вероятнее провайдер/облако; компания — планировать GPU-ноду и бюджет на память/пропускную способность.

Нативная мультимодальность (текст+изображения). В Qwen 3.5 мультимодальность встроена изначально: обучение «с нуля» на тексте и изображениях, а не через отдельную VL-надстройку с энкодером. schedule03:40

• Подход: trained from scratch on text + images.
• Продуктовый критерий: если в сценариях есть изображения (скриншоты, документы, UI), имеет смысл тестировать нативно мультимодальные модели.

Ускорение на long-context: архитектура + multi-token prediction. Автор связывает ускорение с изменениями архитектуры/attention, снижающими потребность в RAM при больших контекстах, и переходом к multi-token prediction. Заявлены цифры на 256k контексте: 19x быстрее Qwen 3 Max и 7.2x быстрее Qwen 3 235B при decoding. schedule04:46

• Заявление по speedup на 256k (decoding):
  • 19x vs Qwen 3 Max
  • 7.2x vs Qwen 3 235B
• Причины: оптимизации под большие контексты + multi-token prediction.

Языковое покрытие и токенизатор. У Qwen 3.5 заявлено расширение мультиязычности и рост словаря токенизатора, что важно для интернациональных продуктов, но требует проверки на целевых языках. schedule05:56

• Языки/диалекты: 119 → 200+.
• Vocab токенизатора: 250K.