Путь к локальной LLM: модель, которой я наконец пользуюсь каждый день

Путь к локальной LLM: как требования ИБ и дух авантюризма привели к 125B-модели под столом — и почему агентам больше не нужно облако

Для меня ИИ-агенты — не демонстрация на презентации, а рабочий инструмент: они пишут код, разбирают инциденты по трассировкам, готовят постановки и прототипы, развивают платформы и помогают с множеством задач бэк-офиса. В компании мы давно внедряем ИИ в процессы и повышаем личную эффективность с помощью агентов. Но по мере роста нагрузки всё настойчивее звучит вопрос — сначала от ИБ заказчиков, затем и от меня самого, когда речь заходит о работе внутренних команд: куда именно отправляются постановки, фрагменты кода и данные? Рассказываю, как я прошёл путь от «это нельзя отправлять в облако» до 125B MoE-модели на собственной рабочей станции, которая справляется с реальными волнами агентных задач со скоростью 22–25 токенов в секунду, качеством лучшего кванта и без передачи данных за периметр =)*

На оригинальность не претендую: статей о локальном инференсе в целом и о Strata в частности мне встречалось немало. Поэтому решил поделиться собственной историей — с конкретным железом, цифрами из реальных сценариев, а не только результатами искусственных замеров генерации, — а заодно рассказать о развитии локального инференса и вопросах ИБ. Возможно, кому-то пригодятся мои измерения и настройки.

Краткие выводы для тех, кто не любит длинные тексты

1. Требования ИБ — не формальность. Постановки, код и данные заказчиков нельзя безоговорочно отправлять в облачные API. Маскирование необходимо как базовая мера гигиены, но решает проблему лишь частично: данные можно восстановить по косвенным признакам, качество на обезличенном контексте снижается, код и конфиги не всегда поддаются маскированию, а метаданные остаются.

2. Локальный контур уже не игрушка. 125B MoE и специализированный движок обеспечивают рабочую скорость на сравнительно недорогом обычном железе: 22–25 t/s генерации и более 500 t/s префилла при качестве лучшего кванта — 93.1% согласия с 8-битным эталоном.

3. Что важно при настройке: скорость кванта определяется не столько качеством, сколько распределением VRAM; обновление движка — самый дешёвый апгрейд (+79% decode, но после каждого обновления нужна перекалибровка); в Windows следует смотреть на commit, а не только на RAM (+48% благодаря pagefile); KV-кеш почти бесплатен, параллельные слоты — нет; спекулятивный декодер практически обязателен.

4. Результат зависит не только от модели, но и от подготовки. Скиллы с выверенными процессами, заранее собранные знания о продуктах — факт-базы и чек-листы — и проверяемый результат через тесты, гейты и e2e позволяют локальной модели выполнять агентные волны при комфортной скорости генерации и префилла. Расследования, ревизии бэклога и реализация по отревьюенному дизайну доступны уже сегодня.

5. Локальный контур — ещё и резервный канал. Настроенные ИИ-процессы продолжают работать, если закончилась подписка, отключили deployment или пропал интернет. А для чувствительных данных локальная обработка может быть единственным допустимым вариантом.

6. Это также лаборатория и испытательный полигон. Собственный инференс показывает, как режимы и параметры движка ведут себя под реальной нагрузкой, включая ту же «карусель» слотов. На нём удобно обкатывать навыки агентов: то, что стабильно работает на локальной модели, как правило, работает и на сильных облачных. Мой прогноз: в ближайшие год-два гибридный подход — облако для дизайна и сложных решений, локальный контур для массовых волн и чувствительных данных — станет нормой для команд разработки. А в энтерпрайзе размещение агентов внутри контура уже сейчас может стать базовым условием внедрения, как сегодня требование к реестру отечественного ПО.

Часть 1. Почему энтерпрайз всё осторожнее относится к облачным API

Мои заказчики — госкорпорации, банки и промышленные холдинги. Здесь пометка «коммерческая тайна» встречается на каждом втором документе, контуры разделены физически, а упоминание ФСТЭК в требованиях — отнюдь не декорация. У нас, кстати, есть сертифицированное СЗИ с четвёртым уровнем доверия ФСТЭК, и в 2026 году мы проходили сертификацию по новому процессу. Когда приходишь к такому заказчику с предложением подключить ИИ, первым спрашивают не о цене, а о том, куда отправляются данные. И это правильный вопрос.

Посмотрим без прикрас, что попадает в облачный API при работе агентов:

• постановки задач — с названиями проектов, контрагентами, суммами, сроками и именами ответственных;

• фрагменты кода, конфигов и CI\CD — с URL внутренних систем, именами серверов, схемами данных, а нередко и ключами доступа;

• логи и фрагменты данных, которые агент собирает в качестве контекста для расследования;

• коммерческая тайна, персональные данные и, перекрестившись, документы ДСП — с ИБ заказчиков и ФСТЭК шутить не стоит;

• и всё это сопровождается метаданными: кто, когда, сколько и о чём спрашивал.

Вот какие проблемы я собрал из собственной и чужой практики:

1. Данные физически выходят за периметр. Они не просто «копируются для анализа», а оказываются на чужой инфраструктуре, в другой юрисдикции и под действием чужих регламентов.

2. Сроки хранения и политики конфиденциальности могут измениться после очередного объявления. Сегодня промпты не используют для обучения, завтра — применяют «для улучшения качества сервиса». Провайдеру выгодно называть такой подход безопасным, но стоит отдельно выяснить, что происходит с запросами через 30 дней.

3. 152-ФЗ и персональные данные. Иностранные API создают отдельный набор рисков, с которыми юрист заказчика порой разбирается дольше, чем длится сам проект.

4. Rate limits и пиковая нагрузка. Агентная работа — это не единичный запрос, а десяток параллельных субагентов с контекстом в десятки тысяч токенов у каждого. Облачный лимит может быть рассчитан на человека, но не на целую орду агентов.

5. Расходы. Агентные циклы потребляют токены нелинейно: один агент-расследователь за вечер способен использовать миллионы входных токенов и исчерпать лимит подписки.

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

Часть 2. Маскирование необходимо, но не решает всё

Первое, что обычно предлагают вместо локального запуска, — маскирование: перед отправкой в облако имена, ИНН, суммы и другие критичные сущности заменяют плейсхолдерами. Это правильная и полезная мера, которая действительно снижает риск. Но полной гарантии она не даёт:

• восстановление по косвенным признакам. Идентификатора задачи, структуры JSON, названий полей и остатков контекста нередко достаточно, чтобы определить заказчика и контракт даже без прямого упоминания;

• снижение качества. Замените отрасль на ORG_1, а продукт на PRODUCT_2 — и модель потеряет существенную часть предметной специфики. Маскирование разрывает смысловые связи, и агент начинает ошибаться именно там, где требуется точность;

• код и конфиги нельзя надёжно обезличить целиком. Удалить название «Росатом» из текста регулярным выражением возможно, а вот убрать ценную информацию из интеграционного конфига или фрагмента схемы БД уже гораздо сложнее;

• метаданные никуда не исчезают. Кто, когда, сколько и с какой периодичностью обращается к сервису — тоже информация, которая передаётся целиком;

• конвейер маскирования сам по себе является программным продуктом. У него есть собственные ошибки, правила и затраты на сопровождение. Как человек, отвечающий за развитие внутренних платформ, я хорошо представляю, во что превращаются «простые» промежуточные конвейеры =)

Поэтому маскирование обязательно как слой гигиены и снимает часть рисков, но не закрывает вопрос полностью. Некоторые задачи — в моём случае это прежде всего агентные волны с кодом и внутренними данными — необходимо обрабатывать локально.

Часть 3. Мой выбор: 125B MoE, которая помещается в 16 ГБ VRAM

Промежуточные варианты я тоже пробовал. Локальные модели класса 30–35B подходят для отдельных задач, но не для полноценной агентной работы. На длинном контексте, строгом соблюдении формата и вызове инструментов они начинают сбоить. Класс модели имеет значение, и здесь на помощь пришла архитектура.

Модель: Qwen3.8-Flash-Next, архитектура qwen4exp. Это MoE с 125 млрд параметров, из которых на каждый токен активируется около 6 млрд. Плотная модель на 125B на потребительском десктопе выдаёт единицы токенов в минуту даже при 4-битном квантовании: примерно 65 ГБ весов приходится проходить целиком. MoE меняет ситуацию: большинство экспертов при обработке конкретного токена не задействовано, поэтому их можно хранить в RAM и обращаться к ним по мере необходимости.

Есть у qwen4exp и особенность, которую легко упустить: помимо 125B основных весов модель содержит около 51 млрд параметров n-gram/PLE-таблиц — 20 миллионов биграмм и триграмм с ключами и значениями в каждом слое. Эти тензоры не занимают VRAM и не участвуют в матричных умножениях: они построчно читаются из RAM. Кроме того, предусмотрен отдельный MTP-слой (Multi-Token Prediction) для спекулятивного декодирования. Поэтому 125B вообще может работать на видеокарте с 16 ГБ: в VRAM достаточно разместить внимание, shared-слои и горячих экспертов. На диске модель в выбранных мной квантах занимает 87–104 ГБ — вполне ожидаемая цена такого решения.

Моё железо — обычный домашний компьютер:

• GPU: RTX 5060 Ti 16 ГБ (Blackwell)

• CPU: Xeon E5-2640 v3 — 8 физических ядер / 16 потоков, AVX2

• RAM: 128 ГиБ DDR4 ECC (успел купить по 7 тысяч за планку на 32 ГБ — ИХУ)

• Диски: SSD на 954 ГБ для моделей, HDD для резервных копий

Важная деталь: DDR4 на этом Xeon обеспечивает около 25 ГБ/с эффективной скорости на характерных для MoE обращениях к памяти — случайных чтениях экспертов, а не последовательных. Это главное узкое место системы, и большая часть моих настроек была направлена на борьбу именно с ним.

Часть 4. Strata: путь от 3 до 25 токенов в секунду на Windows

С чего всё началось

Изначально на станции стояла LM Studio, и первый результат разочаровал: около 60 t/s префилла и 3 t/s генерации. Модель целиком работала на CPU: в тот момент LM Studio ещё не поддерживала архитектуру qwen4 должным образом. Из llama.cpp я выжал максимум: -ngl 99 -ncmoe 999 — неэкспертные слои на GPU, эксперты на CPU — дали 7.4 t/s. Затем правила -ot разместили 4–5 слоёв экспертов целиком в VRAM. Порядок важен: применяется первое совпадение, поэтому частные правила blk.[0-3].ffn_.*_exps.=CUDA0 должны предшествовать общему .ffn_.*_exps.=CPU. Вместе с -ub 4096 это подняло префилл с 44 до 144 t/s, а генерацию — до 9.2 t/s, после чего система упёрлась в возможности DDR4. При этом MTP-драфты unsloth не загружались ни одной официальной сборкой llama.cpp 2.30–2.48: в них отсутствовал тензор output_hc_norm. О спекулятивном декодировании пришлось забыть.

Важный методологический нюанс, который сэкономит время: prefill в MoE-схеме растёт с увеличением длины промпта благодаря амортизации чтения экспертов. На 635 токенах я получил 44 t/s, на 5080 — уже 144. Сравнивать конфигурации корректно только при одинаковой длине промпта. Далее я использую свежий промпт примерно на 10k токенов, а затем — на 16.9k.

Strata и калибровка

Strata (MIT), в отличие от универсального llama.cpp, создана специально для qwen4exp. В ней есть адаптивный кеш горячих экспертов в VRAM — около 700 экспертов на гигабайт, параллельное вычисление экспертов на CPU и GPU, встроенный спекулятивный декодер — сначала MTP-слой, позднее собственный DFlash2, — префилл чанками по 8192 токена и KV-streaming: KV-кеш размещается в закреплённой RAM, а в VRAM остаётся только горячее окно. У Strata есть и собственные кванты: линейка ISTA-DASLab GSQ-RCO на 2.4–3.5 bpw, без четвёртого бита, а также семейство Unsloth UD, поддержка которого появилась в версии 0.1.39.

Установка с квантом IQ3_S и калибровка --calibrate под моё железо сразу дали следующий результат:

Метрика	llama.cpp после настройки	Strata IQ3_S после калибровки
Prefill, промпт ~10k	144 t/s	437 t/s (×3)
Генерация EN / RU	9.2 t/s	28.0 / 24.8 t/s (×3)

Следующий вопрос — контекст. Начинал со 131072 токенов, затем перешёл на нативные 262144: генерация снизилась до 20.4 t/s, префилл остался на уровне около 500 t/s. Небольшая плата за резерв KV оказалась приемлемой. Отдельно измерил vision-энкодер во всех трёх режимах: на GPU фотография обрабатывается за 6.2 с против 14.1 с на CPU, при этом текстовая скорость снижается примерно на 5–9%. Выбрал GPU.

О воркерах: интуитивное правило «чем больше потоков, тем лучше» здесь не действует. Движок это учитывает, что видно в стартовом логе:

CPU pool: 7 workers by default (8 physical cores, 16 logical processors;
bounded by every physical core but the host's)
7 pool workers on logical processors 2,4,6,8,10,12,14, the host thread on 0

В пуле 7 воркеров — по одному на физическое ядро, а восьмое отдано хост-потоку, который управляет GPU и передачей по PCIe. HT-потоки намеренно не используются: ограничение здесь — пропускная способность памяти, а не ALU, и два потока на одном ядре лишь конкурируют за контроллер DDR4. Наши измерения в llama.cpp подтвердили это: 16 HT-потоков не быстрее восьми физических. Главный параметр калибровки — --pcie-frac, доля экспертов, которых выгоднее скопировать по PCIe в VRAM, чем вычислять на CPU. Для моего процессора с медленной DDR4 копирование часто обходится дешевле вычислений. Калибровка определила для IQ3_S значение 0.19–0.20 — на 13–20% быстрее настроек по умолчанию, а для более тяжёлого UD-IQ4_XS — 0.35: чем больше байтов приходится на эксперта, тем выгоднее копирование. Она же подбирает параметры адаптивного кеша (adapt-every 1 / swaps 160 / decay 0.97) и порог спекуляции spec-min-p 0.70. Перебор занимает 20–30 минут; на нестандартном железе калибровкой лучше не пренебрегать.

KV-кеш: большой контекст почти бесплатен, дополнительные слоты — нет

После экспертов KV-кеш — второй по значимости потребитель памяти 125B-модели. Strata обращается с ним интереснее, чем llama.cpp: для каждого слоя в VRAM находится только окно, остальной кеш хранится в закреплённой RAM. Вот стартовый лог для контекста 524288 и KV int8:

KV streaming: 32768 of 524288 cells per QSA layer in VRAM,
the K/V in 6.19 GiB of pinned RAM

Казалось бы, это должно замедлять работу, но почти вся нагрузка попадает в окно VRAM. Вот строка из реальной сессии:

KV streaming: 99.49% of 215868 block reads hit VRAM, 4.4 MiB read from RAM

99.49% чтений KV-блоков пришлись на VRAM, а из RAM за всю сессию было прочитано лишь 4.4 МиБ. На практике большой контекст почти не замедляет генерацию: decode для профилей 262k и 512k различался на единицы t/s.

Мы измерили профили «контекст × количество слотов» на более медленном IQ4_XS с движком 0.1.41. Для 0.1.56 показатель decode можно приблизительно умножить на 1.7:

Профиль	Decode, t/s	Слотов кеша экспертов
262k × 1	17–21	3198
512k × 1	15.6 → на 0.1.56+DFlash2 25.6	1607
512k × 2	10.7 отдельно / 4.5 при парной работе	784
512k × 4	не запускается — VRAM занята сессиями	0

Закономерность очевидна: каждый слот и каждый контекст забирают VRAM у кеша экспертов; второй слот снижает decode на запрос примерно на 50%. Сам контекст при этом обходится почти бесплатно, поскольку KV находится в RAM, а слоты — нет, поскольку сессии занимают VRAM. Я остановился на 512k×1. Эксперимент с 1M пока не запускал: конфиг yarn×4 поверх нативных 262144 подготовлен, KV на 1M занимает около 12.4 ГиБ pinned RAM против 3.06 ГиБ на 262k. По тестам сообщества на быстром железе префилл не снижается, но у нас ожидается около 13–17 t/s decode, а рабочих причин для такого контекста пока нет.

Отдельно проверили параллельные запросы. Бенчмарк с четырьмя запросами на одну тему показал «×3.6», но причиной оказался прогретый кеш экспертов — до 96% попаданий и 70–90 t/s для отдельных запросов, — а не параллелизм. Запросы на разные темы показали реальную картину: Strata обрабатывает одну последовательность за раз по FIFO, а параллельные клиенты получают около 50% прироста совокупной производительности благодаря перекрытию префилла и декода. Полезно, но не решает всё.

Кванты: скорость определяет не качество, а распределение VRAM

Квант	Эксперты, ГиБ	top-1 vs Q8	Decode, t/s	Prefill, t/s	Назначение
IQ3_S	~50	—	~25.6*	~610*	удалён с диска
UD-IQ4_XS	59.5	88.9%	24.7	612	быстрая альтернатива
UD-Q4_K_XL	66	93.1%	22.0–23.5	528	основная модель

Переход с трёхбитного кванта на четырёхбитный поначалу снизил скорость генерации на 40% — с 28 до 17 t/s. Дело оказалось не в «плохом кванте», а в физических ограничениях железа: на токен приходилось на 19% больше байтов — 59.5 ГБ экспертов против 50 ГБ, — а в том же объёме VRAM помещалось на четверть меньше горячих экспертов: 3198 слотов кеша против 4192 у лёгкого IQ3_S. Отсюда — больше передач по PCIe и обращений к DDR4. Лог подтверждает, что все эксперты находятся в RAM (blob reads from the file: 0): проблема не в диске и не в объёме доступной памяти. Калибровка подняла скорость четырёхбитного кванта с 11–15 до 14–17 t/s, после чего проявился потолок моей DDR4. Зато лучший квант показывает 93.1% согласия с 8-битным эталоном против 88.9%. Я готов пожертвовать 10% скорости decode ради 4.2 процентного пункта качества: основной моделью стал UD-Q4_K_XL, а IQ4_XS остался в качестве переключаемой альтернативы на ступень ниже.

Версия движка — самый доступный апгрейд

Движок заслуживает отдельного разговора: за полтора месяца я сменил три версии, и каждая заметнее влияла на результат, чем любая ручная настройка.

Обновление с 0.1.30 до 0.1.41 вместе с поддержкой квантов unsloth само по себе ускорения не дало. Зато повторная калибровка подобрала другие параметры и добавила 20%: IQ3_S достиг 34.4 t/s против прежних 28.6. Здесь обнаружилась неочевидная ловушка: меню --calibrate при нескольких конфигах сортирует их по mtime, поэтому ответ через pipe может запустить калибровку не той модели. Проверять нужно значение pack в cmdline процесса.

Переход с 0.1.41 на 0.1.56 принёс скачок, которого не ждёшь от минорного релиза. Замеры IQ4_XS за один день: 14.3 t/s на 0.1.41 с MTP → 24.4 на 0.1.56 с MTP → 25.6 t/s и 616 t/s prefill с новым драфтером DFlash2. Итого +79% decode и +53% prefill. Часть прироста обеспечила сама версия, в том числе выход из зоны WDDM LOW: на 0.1.41 после загрузки оставался слишком маленький резерв VRAM. Ещё около 5% добавил DFlash2, собственный спекулятивный декодер Strata. Он использует окна до шести токенов; у меня принимается 89% драфтов — 130 из 146 в контрольном прогоне, а на тяжёлом Q4_K_XL доля попаданий в кеш экспертов составляет 47–53%. Спекулятивный декодер здесь практически обязателен: это разница между 17 и 23 t/s на том же железе.

Pagefile: когда ограничивает не RAM, а commit

Пожалуй, самая неожиданная находка. Strata размещала экспертов в RAM с бюджетом --resident-budget-gib 75, но при 80 ГиБ свободной физической памяти получала только 59.8 ГиБ и прямо сообщала об этом в логе:

--resident-budget-gib 75.00 exceeds available commit (64.04 GiB minus
4 GiB headroom and a 0.25 GiB margin): 59.79 GiB

Ограничением оказался Windows commit limit — RAM плюс pagefile, а не объём физической RAM. С системным файлом подкачки лимит составлял около 136 ГиБ, и часть экспертов попадала в file tier, откуда считывалась с диска при каждом проходе. Решение — фиксированные файлы подкачки: 48 ГБ на F: и 16 ГБ на C:, что подняло commit примерно до 192 ГБ. Результат на Q4_K_XL: decode 15.1 → 22.3 t/s (+48%), prefill 407 → 528, в памяти находятся все 70.3 из 70.3 ГиБ, file tier 0.0 GiB, blob reads from the file: 0. На IQ4_XS эффект был почти незаметен: он и прежде помещался целиком. Pagefile здесь нужен для увеличения commit-лимита, сам файл почти не читается. По пути выяснилось, что Windows молча не создаёт pagefile на USB-диске: мой SSD с моделями как раз подключён по USB, поэтому пришлось использовать внутренний диск. А возражение «pagefile на HDD — это ужасно» здесь неприменимо: он страхует commit-лимит, а не работает как активный своп.

Эксплуатационные ловушки

• WDDM: если после загрузки модели остаётся меньше 256 МиБ свободной VRAM, decode замедляется примерно в семь раз: драйвер переходит в режим LOW. Диагностика — строка VRAM free в логе, решение — --vram-reserve-mib. Я оставляю около 1.8 ГиБ резерва.

• Деградация при долгой работе: примерно через 18 часов свежий префилл упал с 565 до 52 t/s, то есть в 10.9 раза. Уровни кеша движка деградируют; помогает перезагрузка модели. Моё правило: если свежая сессия стартует медленнее 450 t/s, сервер нужно перезапустить, не дожидаясь дальнейшего падения.

Итоговая лестница производительности

Конфигурация	Prefill	Gen/Decode
LM Studio по умолчанию	~60	~3
llama.cpp, -ot + ub4096 — потолок DDR4	144	9.2
Strata IQ3_S, 0.1.30, калибровка	437	25–28
Strata IQ3_S, 0.1.41, повторная калибровка	~470	30–34
Strata UD-IQ4_XS, 0.1.41 — повышение качества	474	14–17
Strata UD-IQ4_XS, 0.1.56 + DFlash2 + pagefile	616	25.6
Strata UD-Q4_K_XL, 0.1.56 + DFlash2 + pagefile — основной профиль	528	22.0–23.5

Итоговый профиль: UD-Q4_K_XL, контекст 524288, один слот, KV int8 и resident-окно 32768, DFlash2, pcie-frac 0.35, семь воркеров, vision на GPU, резерв VRAM около 1.8 ГиБ, все 70.3 ГиБ экспертов закреплены в RAM. Сервер доступен локально и снаружи через rathole-туннель. На скорость туннель, к слову, не влияет: 17.4 t/s через публичный URL и столько же локально. Персональное «облако» для одного человека =)

Часть 5. Главное: что модель сделала на практике — кейсы из логов

Скорость без практической пользы остаётся игрушкой. В качестве агентного харнесса я использую opencode v2 и КАПАЙ, анонс которого скоро появится в ПРИИСК. Модель подключена как обычный провайдер: доступны те же сессии, субагенты и инструменты. Ниже — три октябрьских кейса; все цифры взяты из логов.

Кейс 1. Расследование и исправления по трассировкам: один день полностью на локальной модели

31 октября сработала типовая промпт-команда «аудит трассировок и итогов работы команды аудита»: мы проверяем ошибки в трассировках production-платформы, ищем первопричины и исправляем их. Вся волна — от первого промпта до коммитов — прошла на локальной qwen3.8-flash-next:

1. Лид-сессия с 62k выходных токенов разобрала журнал аудита и распределила блоки работ.

2. Субагент-расследователь на 47k токенов в режиме read-only изучил SQL-выборки production-трассировок и нашёл первопричины. Узким местом оказался процесс гейта, а не хост: eventLoopDelayMaxMs=95563, «process was frozen ~84354ms», 25 событий заморозки длительностью 60–293 секунды за исследуемый период. Триггеры — горячая перезагрузка конфига на 84–96 секунд (12:15:15 reload detected → 12:16:51 applied — вот и «быстрый патч конфига») и хроническая нехватка heap: 606 critical memory-pressure за три дня, 951 из 960 MiB heap в момент заморозки.

3. Рефери-гейт на 11k токенов проверил дизайн исправлений: два варианта отклонили до написания кода, третий приняли. Польза рефери подтверждена практикой.

4. Субагент-исполнитель на 46k токенов реализовал шесть исправлений с тестами: маппинг ошибок API — 400/404/401/403/503/502 по классам, предварительную проверку координат без обращения к апстриму, single-flight для circuit breaker с Retry-After, каскад резолвера и другие изменения. В отчёте субагент указал: «все 6 фиксов реализованы, гейты зеленые», приложив список файлов и количество тестов по каждому исправлению.

5. E2E-спеки на 21k токенов описали приёмочные сценарии классов для этих исправлений.

6. Завершение волны: рефлексия сессии, фиксация уроков и 8 локальных коммитов. Все сделаны с pathspec, без захвата чужих изменений — при параллельных сессиях это отдельная дисциплина.

За один рабочий день: инцидент в проде → первопричина → проверенный дизайн → шесть исправлений с тестами → e2e-спеки → коммиты.

Кейс 2. Доработка блока «Аудит документов»: от постановки до интерфейса за день

29 октября выполнилась промпт-команда «доработки» для модуля распознавания документов: список моделей по ключам, повторное распознавание и критерии «проблемных» страниц. Вся работа — от постановки до кнопок в UI — также прошла на локальной qwen3.8-flash-next:

1. Лид-сессия примерно на 20k токенов приняла постановку и распределила блоки: R1–R4 на исследования, B1–B4 на реализацию.

2. Три субагента-исследователя по 73–81k токенов каждый в режиме read-only собрали факты по коду. R1 выяснял, какие модели доступны по ключу и где хранить список, включая сценарий полной локальной работы на уровне Шаблона; R2 изучал повторное распознавание и мультимодельность; R3 — критерии «проблемных» документов.

3. Исполнители R1–R4 по 8–11k токенов закрыли исследовательские блоки решениями с факт-базами.

4. Рефери-гейт на 17k токенов проверил план реализации B1–B4 до написания кода, а не после.

5. Субагент-исполнитель B1 на 22k токенов реализовал активный ключ пользователя в Профиле: поле в схеме Prisma, каскад резолвера «явный выбор сессии > активный ключ > новейший», два новых POST-роута с аудитом и проверкой владения, бейдж активного ключа и кнопки в UI. Вечером того же дня начался следующий блок — B2a, мультивыбор способов OCR.

6. Тесты на 133k токенов включали приёмочные e2e-сценарии классов для доработок, автотесты и само тестирование через Playwright.

За один рабочий день: постановка → три исследования → проверенный план → схема БД, миграция, API, фронтенд и тесты. Всё — под моим ревью.

Кейс 3. Месяц работы: не только счётчик токенов

Один из постоянных треков весь октябрь выполнялся на локальной qwen3.8-flash-next: 60 сессий, более половины из них — волны субагентов. Состав работ за месяц выглядел так:

1. Ревизия бэклога — 9 запусков. Дюжина параллельных read-only субагентов проверяла свои группы задач по tech debt и выносила вердикт «актуальна / уже исправлена» с подтверждениями в формате файл:строка.

2. Доработки аудита документов — 3 запуска; пример приведён во втором кейсе.

3. Волны traces — примерно дважды в неделю; пример описан в первом кейсе.

4. Уборка md — примерно дважды в неделю: проверка статусов рабочих md-файлов и наведение порядка.

5. Эксперименты — 26 сессий различных доработок.

За месяц: 60 сессий → 90.2 млн входных и 4.2 млн выходных токенов → 963 млн токенов прочитано из кеша → расходы только на электричество: около 300 Вт, сотни рублей. Ноль рублей за токены, ноль байт за периметр.

О деньгах скажу кратко. Сама станция стоит относительно недорого: списанный серверный Xeon, одна потребительская видеокарта и много бывшей в употреблении ECC-памяти укладываются в бюджет обычного рабочего ПК, а не специализированного ИИ-сервера. При этом аналогичные объёмы в облаке на модели flash-класса стоили бы единицы долларов. Экономия здесь не главный довод, а приятное дополнение.

Главных аргументов три, и ни один не связан с деньгами.

Первый — защита чувствительных данных. Постановки с бюджетами и контрагентами, код с внутренними URL, production-логи, коммерческая тайна, персональные данные, ДСП, документы заказчиков и другая конфиденциальная информация обрабатываются на машине и вообще её не покидают.

Второй — резервный канал для настроенных ИИ-процессов. Облачная зависимость может подвести по-разному: у провайдера исчерпался лимит или бюджет, deployment сняли с обслуживания, изменились условия или просто пропал интернет. На моих шлюзах облачные модели порой выбывают буквально за считаные дни: то лимит закончился, то возвращается 404. При этом настроенные процессы — скиллы, промпт-команды и конвейеры субагентов — продолжают работать в локальном контуре, где есть и собственная модель, и собственный шлюз. Это не самый интеллектуальный из доступных режимов, но он работоспособен. Речь уже об обеспечении непрерывности, а не просто об эксперименте.

Третий — лаборатория для получения практического опыта. Когда инференс находится под столом, можно самостоятельно исследовать движки, режимы и параметры и выяснять, как они ведут себя под нагрузкой, а не только читать документацию. Свежий пример за ноябрь — «карусель» слотов и потеря контекста. Симптом: агентная сессия с контекстом на 300–400K токенов работает нормально, пока между ходами не проходят чужие небольшие вызовы от другого клиента или tool-запроса. После этого следующий ход выглядит как зависание модели. Логи показали, что показатель повторного использования контекста — доля KV-префикса из кеша — падал до нуля, а сервер незаметно перечитывал весь промпт с начала: 300–400K токенов за 540–730 секунд, в течение которых генерация не идёт. Клиент видит «зависание», хотя сервер честно работает — просто читает, а не генерирует. Причин оказалось две: вытеснение кеша диалогов в однопоточном режиме и «карусель» слотов в параллельном. Сессия попадала не в свой слот, видела чужой KV и теряла собственный контекст. В новой версии движка слоты сделали «липкими», добившись 97–98% попаданий в свой контекст, но параллельный режим потерял 41% скорости декода. В результате профиль можно осознанно выбирать под нагрузку: один режим для редких длинных сессий, другой — для частых коротких, например heartbeat-агента с ходом раз в 5–10 минут, который по общему времени выполняется в 2.3 раза быстрее. Переключение — одной строкой конфига. Такой опыт у облачного API не купишь: там видно только, что модель молчит, а здесь в каждой serve-строке лога есть метрика reuse, объясняющая причину.

Есть у лаборатории и неожиданный бонус: это отличный полигон для проверки навыков агентов. Скиллы и промпт-команды, которые устойчиво работают на более медленной локальной модели, чувствительной к контексту и очереди параллельных субагентов, обычно хорошо работают и на сильных облачных моделях. Практическое правило простое: сначала доводим процесс здесь, затем переносим его туда. Все кейсы из статьи прошли такую обкатку.

Отдельно подчеркну роль скорости: именно она превращает всё описанное из теории в рабочую практику. При 22–25 t/s decode и более 500 t/s префилла агент обрабатывает контекст в десятки тысяч токенов за секунды, ответ в реальном времени появляется быстрее, чем его успеваешь читать, а волна субагентов не растягивается на сутки. Локальная модель перестаёт восприниматься как запасная и становится полноценным инструментом конвейера.

Где локальная модель всё ещё уступает ведущим облачным? На самых сложных развилках проектирования и в длинных многошаговых рассуждениях без подготовленного контекста старшая облачная модель рассуждает точнее. Но главное наблюдение за месяц: результаты в приведённых кейсах обеспечила не только «умность» модели, а подготовка харнесса — скиллы с отлаженными процессами, заранее собранные знания о продуктах, факт-базы с выжимками файл:строка, чек-листы валидации, паспорта блоков и контекст, который не нужно собирать заново. При комфортной скорости генерации и префилла и достаточно подготовленном харнессе локальная модель тоже даёт хороший результат. В отдельных сценариях уже не так важно, какая именно модель находится под капотом. Оркестрация и дисциплина промптов значат гораздо больше, чем дополнительные условные 10% «умности».

И напоследок: эксперименты не закончились, они продолжаются постоянно. Есть ещё один сервер — полная противоположность Windows-станции: бездисплейный Linux-риг на списанном майнинговом железе. В нём плата из майнинг-фермы с множеством PCIe-слотов, двухъядерный Celeron без AVX, 8 ГБ RAM без свопа и четыре бывшие в майнинге P104-100 на 8 ГБ каждая (Pascal, sm_61), купленные по 2–3 тысячи рублей за штуку. Вся сборка обошлась примерно в 20 тысяч. Круглосуточно она запускает 35B MoE-модель Cyber-Tiel-Coder-35B-A3B для агентов, бота и других экспериментов: 27–30 t/s генерации, префилл до 785 t/s, контекст 262K и доступ снаружи по HTTPS. Видеоподсистема всего рига стоит дешевле одной бывшей в употреблении RTX 3060. А ещё за ним стоят полтора месяца железной драмы: восемь ошибок Xid 79 «GPU fallen off the bus» за месяц, сервер-зомби с «health: ok» при неработающей генерации и SSD, который умудрялся по-разному читать один и тот же участок.

Если интересно, пишите в комментариях — подготовлю вторую часть =)

ЗЫ. Иногда полезнее не отмахиваться слайдами о «безопасности облаков», а разобраться в вопросе и показать реальные логи и личные кейсы =) ЗЫЫ. Фактуру для этой статьи помогала собирать всё та же Qwen3.8-Flash-Next =) ЗЫЫЫ. И, конечно, внутри корпоративного контура ПРИИСК у нас работает множество других локальных моделей. Одна создавала картинки, вторая превращала мои голосовые замечания в текст и постановку для Qwen, третья проверяла орфографию.

 

Источник