Путь к локальному 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, когда работают агенты:

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

• куски кода и конфигов, CI\CD - с 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 под мое железо дали сразу:

Дальше - контекст. Стартовал со 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):

Правило, которое здесь видно: каждый слот и каждый контекст отъедает 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

Переход с «трешки» на квадробит сначала стоил мне -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 minus
4 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 - рестарт сервера, не ждать.

Итоговая лестница

Финальный профиль: 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 вторая, а проверку на орфографию - третья.