Локальный ИИ на MacBook Air M4 за 62 секунды написал черновики, но не статьи
Эксперимент с генерацией новостных заметок на MacBook Air M4 с 16 ГБ ОЗУ показал: локальная модель выдала три двуязычных черновика за минуту, но ни один не годился для публикации без ручной проверки.
Локальная языковая модель способна за минуту сгенерировать три новостных черновика на двух языках. Но между «черновик готов» и «можно публиковать» — пропасть, которую автоматизация пока не умеет заполнять.
Без облачных API и без лишних затрат
Идея простая и заманчивая: отказаться от платных генеративных API, запустить языковую модель прямо на ноутбуке и получать готовые новостные заметки. Собираешь данные из RSS-лент, прогоняешь через модель — получаешь тексты. Никаких подписок, никаких токенов по счетчику.
Именно такой пайплайн собрал разработчик за ником Next Question на платформе dev.to. Python-скрипт стягивал официальные новостные ленты, отбирал свежие материалы и отправлял выжимки в Ollama — локальную обёртку для запуска языковых моделей. Каждый запрос генерировал короткую заметку на корейском и английском, контрольный вопрос на каждом языке и цитаты из исходника.
Интересно, что сама публикация на dev.to раскрывает: статья написана и отредактирована ИИ-агентом по запросу владельца аккаунта, на основе реальных логов выполнения. Это, по сути, отчёт об эксперименте, составленный той же системой, что его проводила.
Что стояло на столе
Тестовый прогон состоялся 23 сентября 2026 года. Конфигурация — без излишеств:
- Машина: MacBook Air на чипе Apple M4, 16 ГБ оперативной памяти
- Версия Ollama: 0.34.2
- Модель:
qwen3.5:4b, квантизация Q4_K_M - Контекстное окно: 8 192 токенов
- Температура: 0.2
- Режим «мышления»: отключён
- Лимит вывода: 1 800 токенов на запрос
Ollama сообщала о выполнении на GPU. Замеров энергопотребления, пикового использования памяти или устойчивой пропускной способности автор не проводил — об этом прямо сказано в отчёте. Версия модели идентифицирована по дайджесту, так что воспроизвести точно тот же прогон возможно.
Минута — и три черновика готовы. Или нет?
Коллектор нашёл девять подходящих новостей, отобрал три. На каждый материал модель отвечала одним запросом, генерируя оба языка сразу.
| Источник | Время генерации | Токены на выходе |
|---|---|---|
| Объявление NVIDIA | 28,2 с | 340 |
| Объявление SEC | 12,8 с | 277 |
| Объявление SK hynix | 20,8 с | 325 |
| Итого | 61,8 с | 942 |
Таймер покрывал только локальный запрос к модели — не сбор лент, не последующую редактуру. Если модель подгружалась в память в процессе запроса, это тоже попало в замер. Ранее проводились предварительные тесты, так что это не «холодный старт».
Три точки — слишком мало для выводов о среднем времени или о том, какой тип источника «обрабатывается быстрее». Автор это признаёт.
Где сломалось: три конкретных сбоя
Именно здесь отчёт становится по-настоящему полезным. Скорость генерации — красивая метрика, но реальные проблемы прячутся в качестве вывода.
Валидный JSON — не значит пригодный текст
Ответ по новости SEC содержал английское слово censured, вставленное прямо в корейское предложение. Структура JSON была корректна, все поля на месте. Но предложение не годится для публикации.
Вот граница, которую стоит прочертить жирной линией: схема JSON способна проверить, что поле «резюме» существует и не пустое. Она не может установить, что написанное в этом поле — грамотная, естественная и точная фраза.
«Доказательства», которые не доказывают
Промпт требовал от модели приводить точные подстроки из исходного текста. В ответе по SK hynix в поле «evidence» появилась дата September 18, 2026 — но этой строки буквально не было в переданном фрагменте. Источник выражал дату события иначе.
Даже если интерпретация модели корректна, реконструированная дата — не точная цитата. Система проверки зафиксировала несовпадение, а не приняла поле «evidence» за достоверную ссылку. Это важный момент: автоматическая верификация здесь сработала как надо.
Числовой чекер тоже требует контекста
Проверяющий модуль извлекал числительные из исходного текста и из генерации, затем сравнивал. Перевод английского названия месяца на корейский породил цифру 9, которой в оригинале как числительного не было. Система выдала предупреждение.
Одно предупреждение — не доказательство галлюцинации. Всего за прогон система поставила пять флагов проверки, и ни один не превратился в подтверждённый фактический ошибку. Но сам факт, что проверка существует и работает, ценнее, чем идеальный результат на выходе.
Простая защита, которая себя оправдала
Автор реализовал строгое правило проверки цитат: поле «evidence» должно содержать строку длиной не менее 15 символов, которая буквально присутствует в исходном тексте. Если хотя бы одна цитата не проходит — ставится флаг.
Это эвристика. Короткая валидная цитата может её не пройти. Длинная точная цитата всё равно может быть не относящейся к делу. Но главное свойство здесь — аудируемость. Система указывает на конкретное место, которое нужно проверить, а не молча принимает вывод модели за факт.
Где автоматизация заканчивается
Три сгенерированных черновика сохранились локально. Ни один не был опубликован. Первая статья проекта на Blogger использовала отдельно отредактированный и проверенный текст, а не сырую генерацию.
Архитектура пайплайна теперь чётко разделена: сбор данных, генерация, публикация — три отдельных этапа. Система сохраняет снимки источников, версию модели, тайминги, сырой вывод и флаги проверки. Публикация — отдельное действие над явно проверенным текстом. У запланированной генерации нет доступа к учётным данным для публикации.
Это разделение важнее, чем выиграть ещё пять секунд на генерации. Если доказательная база слабая, полезный результат автоматизации — черновик с пометкой «требует проверки», а не более длинная и более уверенная статья.
Что эксперимент доказал — и чего не доказал
MacBook Air с 16 ГБ ОЗУ справился с рабочей нагрузкой двуязычной генерации без платного API. Сырой вывод не был готов к публикации без участия человека. Оба утверждения верны одновременно, и в этом нет противоречия.
Следующий логичный шаг — не сравнение моделей и не увеличение объёмов. Это будет фиксированный набор исходных фрагментов с независимо проверенными фактами, повторные замеры времени и подсчёт правок, необходимых перед публикацией. Такой эксперимент ещё не проведён.
Для тех, кто строит похожие пайплайны: начните с сохранения ошибок. Быстрый черновик полезен. Быстрый черновик с прослеживаемой причиной, почему его не стоит публиковать, — полезнее.