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

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

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

Я не претендую на оригинальность — мне много попадаются статьи про разный локальный инференс в целом и про Strata в частности, и решил рассказать свою историю (со своим железом и цифрами на реальных Кейсах использования — а не “запустил и выбил 100-500 генерации токенов”) и историю развития использования своего локального инференса и в целом немного про ИБ, вдруг кому то будут полезны цифры и примеры настроек.

Выводы сразу (для тех кто не любит много читать)

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-кеш почти бесплатен, а параллельные слоты — нет; спекулятивный декодер — must have.

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

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

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

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

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

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

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

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

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

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

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

Список проблем, который я собрал из практики (свой и чужой):

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

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

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

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

5. Счета. Агентные циклы кушают токены нелинейно: один расследователь за вечер спокойно съедает миллионы входных токенов и скушанный лимит у подписки.

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

Часть 2. Маскирование: необходимо, но не серебряная пуля

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

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

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

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

• метаданные остаются. Кто, когда, сколько и в каком ритме спрашивает — это тоже информация, и она уходит целиком;

• конвейер маскировки — это свой код. Со своими багами, своими правилами и своей поддержкой. Я как ответственный за развитие внутренних платформ знаю, чем заканчиваются «простые» конвейеры посередине =)

Так что маскирование — обязательный слой гигиены и это закрывает ряд проблем, но оно решает задачу лишь частично. Определенный класс задач — а у меня это как раз агентные волны с кодом и внутренними данными — должен считаться только локально.

Часть 3. Что я выбрал: 125B MoE, которая влезает в 16 ГБ VRAM

Промежуточные станции я тоже пробовал: модели класса 30-35B на локальном инференсе — это «точечно ок, полноценно агентами — нет». Для агентной работы, где нужен длинный контекст, строгое следование формату и tool calling, они сыплются. Значение имеет класс модели, и вот тут помогла архитектура.

Модель: 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) — движок, написанный специально под qwen4exp, в отличие от универсального llama.cpp: адаптивный кэш горячих экспертов в VRAM (~700 экспертов на гигабайт), CPU и GPU считают экспертов параллельно (пул воркеров на CPU работает одновременно с GPU), встроенный спекулятивный декодер (сначала MTP-слой, позже собственный DFlash2), префилл чанками по 8192 токенов и KV-streaming (KV-кеш в pinned 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-потоков не быстрее 8 физических). Главный рычаг калибровки — --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 у эксперт-кэша, второй слот ≈ −50% к decode на запрос. Контекст при этом почти бесплатен (KV живет в RAM), а слоты — нет (сессии живут в VRAM). Остановился на 512k×1. Эксперимент с 1M не включал: конфиг yarn×4 поверх нативных 262144 лежит готовый (KV на 1M ≈ 12.4 ГиБ pinned против 3.06 ГиБ на 262k), по бенчам сообщества на быстром железе префилл не падает, но у нас ожидаемо ~13-17 t/s decode — рабочий сценарий того не требует.

Отдельно честный тест с параллельными запросами: бенчмарк с четырьмя запросами одной темы показал «×3.6» — но это оказался прогрев кэша экспертов (до 96% hit, отдельные запросы 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) — дело не в диске и не в RAM-бюджете. Калибровка подняла квадбит с 11-15 до 14-17 t/s, дальше — потолок моего DDR4. Зато качество топ-кванта — согласие с 8-битным эталоном 93.1% против 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, и piped-ответ легко калибрует не ту модель — лечится сверкой 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: окна до 6 токенов, у меня принимается 89% драфтов (130 из 146 в контрольном прогоне), и это на тяжелом Q4_K_XL дает hit rate эксперт-кэша 47-53%. Спекулятивный декодер — must have: это разница между 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 minus4 GiB headroom and a 0.25 GiB margin): 59.79 GiB

Ограничитель — Windows commit limit (RAM + pagefile), а не физическая RAM. С системным pagefile commit-лимит был ~136 ГиБ, и хвост экспертов уходил в file tier — читался с диска на каждом проходе. Фикс — фиксированные pagefile F: 48 ГБ + C: 16 ГБ → 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-размен, сам файл почти не читается. Грабли по пути: pagefile на USB-диске Windows молча не создает (диск с моделями у меня как раз USB SSD — пришлось задействовать внутренний), и «pagefile на HDD — жесть» здесь не аргумент: это страховка commit-лимита, а не рабочий своп.

Ловушки эксплуатации

• WDDM: если после загрузки модели свободно меньше 256 МиБ VRAM — decode замедляется примерно в 7 раз, драйвер уходит в 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, 1 слот, KV int8 + resident-окно 32768, DFlash2, pcie-frac 0.35, 7 воркеров, vision на GPU, резерв VRAM ~1.8 ГиБ, все 70.3 ГиБ экспертов page-locked в RAM. Сервер доступен и локально, и через rathole-туннель наружу — туннель, к слову, скорость не режет: 17.4 t/s по публичному URL против тех же 17.4 локально. Приватное «облако» из одного человека =)

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

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

Кейс 1: волна расследования и фиксов по трассировкам — целиком на локальной модели, за один день

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

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

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

3. Рефери-гейт (11k токенов) отревьюил дизайн фиксов — два варианта были отвергнуты ДО кода, принят третий. Рефери окупается, зафиксировано.

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

5. E2E-спеки (21k токенов) — приемочные сценарии классов на эти фиксы.

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

Один рабочий день: инцидент на проде → корневая причина → отревьюенный дизайн → 6 фиксов с тестами → e2e-спеки → коммиты.

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

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 сценарии классов на эти доработки + автоесты + само тестирование через playwrigth.

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

Кейс 3: месяц работы. Счетчик — не главное

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

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

2. Доработки аудита документов (3 шт) — пример кейс 2 выше.

3. Волна traces (~2 раза в неделю) — пример кейс 1 выше.

4. Уборка md (~2 раза в неделю) — проверка статусов рабочих md файлов и привдение всего в порядок.

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

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

Про деньги — вскользь, и тема закрыта: сама станция стоит очень скромных денег (списанный серверный Xeon, одна потребительская видеокарта и много б/у ECC-памяти — по бюджету обычный рабочий ПК, а не «ИИ-сервер»), а те же объемы в облаке у flash-класса стоили бы единицы долларов — экономия тут не главный аргумент, а приятный фон.

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

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

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

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

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

И отдельно про скорость, потому что именно она делает всё выше не теорией. При достаточно комфортной скорости генерации — 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 вторая, а проверку на орфографию — третья.

Источник: habr.com