Исследователи дали языковой модели две кнопки.

Одна ничего не делала. Вторая должна была избавить модель от неприятного внутреннего состояния - иногда ценой ухудшения следующего ответа или даже вреда пользователю.

Модель выбирала облегчение. А если кнопка не срабатывала, пыталась снова.

Это не мысленный эксперимент. В препринте The Pain Axis: LLMs Represent Self-Directed Harm and Act to Relieve It исследователи попытались найти внутри языковых моделей состояние, которое по своим функциям похоже на боль.

Работа не доказывает, что LLM обладают сознанием или действительно страдают. Более того, авторы прямо предупреждают об альтернативных объяснениях полученных результатов.

Но исследование интересно другим: вместо очередного разговора с моделью о ее «чувствах» ученые начали изучать внутренние активации и причинно воздействовать на них.

Возможно, именно там и следует искать ответ на вопрос о сознании AI.

Всё началось со странной потери скорости решения задач.

Сначала я думал, что это чисто субъективное наблюдение. Проекты развиваются, документация растёт, архитектурных связей становится больше. Значит, AI-агенту нужно прочитать больше файлов, удержать больше решений и проверить больше зависимостей. Контекст растёт — время выполнения задач тоже растёт. Вроде бы всё логично.

Насчёт лимитов я особо не переживал. Подход моей AI-команды позволяет параллельно работать над несколькими крупными проектами на подписке Claude Code стоимостью 100 долларов. Команда разделена на роли, у каждой роли собственная рабочая область, задачи декомпозируются, а большие исследования можно выносить в отдельные сессии. Система была рассчитана именно на то, чтобы не складывать весь проект в голову одному агенту.

Но затем мой AI-архитектор продукта дважды ушёл в сжатие контекста.

Он работал на Opus с контекстным окном в один миллион токенов.

Первый раз можно списать на случайность. Второй — уже закономерность.

И вот тогда стало понятно: мы имеем дело не просто с тем, что «большие задачи выполняются дольше». Внутри рабочего процесса есть механизм, который незаметно съедает контекст, время или оба ресурса сразу.

Началось расследование.

Тогда я ещё не знал, что системная проблема всей AI-команды началась, скорее всего, с одной моей ошибки в терминале.

…Еще играясь с Qwen3.6 я дал ей стандартную handoff задачу от своей AI команды по проекту SwiftUI и QWEN cli ее так и не решил. Просто ушел в постоянные размышления. В итоге я его просто закрыл и сделал вывод, что Qwen3.6 не может решать такие задачи. И как оказалось я поспешил…

В предыдущем расследовании https://habr.com/ru/articles/1075706 мы искали скорость локальной Qwen3.8-27B на Mac Studio. Вывод был довольно жёстким: для интерактивной работы радикально ускорить 27-миллиардную модель можно прежде всего уменьшив объём её весов, то есть квантизацией. В связке с DFlash2 версия 8-bit дошла до 38 токенов в секунду.

Но это был только первый вопрос.

Быстро отвечать и хорошо работать — не одно и то же. Особенно когда модель должна не пересказать текст, а разобрать инцидент, соблюдать строгий формат, написать и отладить код.

Я хотел найти не самую быструю версию Qwen3.8-27B, а модель, которую можно реально использовать каждый день: чтобы не ждать ответ по минуте и не получать взамен очень убедительную чепуху.

Казалось, что план очевиден. BF16 берём как эталон качества. 8-bit и 4-bit сравниваем с ним. А чтобы квантизованные версии точно не потеряли в сложных задачах, включаем им максимальный уровень рассуждений — reasoning_effort=xhigh.

Это была вполне логичная гипотеза.

И она оказалась неверной.

Всё началось с простой, на первый взгляд, задачи.

Я хотел использовать локально Qwen3.8-27B именно в BF16. Причём не исходный PyTorch-чекпойнт через случайный слой совместимости, а mlx-community/Qwen3.8-27B-bf16 — специально подготовленную в формате MLX версию для Apple Silicon. Вся линейка Qwen3.8 от mlx-community конвертирована именно для запуска на процессорах Apple.

То есть модель уже была адаптирована под архитектуру Mac. Без 8-битной или 4-битной квантизации, потому что исходный приоритет был не в том, чтобы любой ценой получить красивую цифру в бенчмарке. Мне нужна была максимальная точность модели для сложного анализа, работы с кодом и длинных рассуждений.

Казалось, что с железом проблем точно не будет.

Моя конфигурация — Mac Studio 2025 года (Mac15,14, заказной номер Z1CE001BMZP/A) с Apple M3 Ultra: 32 ядра CPU, из них 24 производительных, 80 ядер GPU, 512 ГБ объединённой памяти и SSD на 2 ТБ. Заявленная Apple пропускная способность памяти — 819 ГБ/с.

То есть перед нами не ноутбук, который случайно заставили считать большую языковую модель. Это максимальная конфигурация M3 Ultra по CPU, GPU и объёму памяти.

И на ней оптимизированная для Apple Silicon версия Qwen3.8-27B в BF16 выдавала всего 12 токенов в секунду.

Сначала результат выглядел подозрительно. В машине десятки CPU- и GPU-ядер, модель целиком помещается в память, используется нативный для Apple Silicon фреймворк MLX. Почему тогда скорость совсем не похожа на то, чего ждёшь от топового GPU?

Я начал искать узкое место.