Как всё началось

Эта история начинается с реального продакшен-инцидента.

По графикам в Grafana я вышел на гипотезу, что в одном из сервисов наблюдается утечка соединений. Картина была довольно характерная: пул постепенно забивался, количество реально выполняющихся запросов этому совершенно не соответствовало, а рестарт сервиса временно возвращал всё в норму.

Недолго думая, я попросил Claude составить по инциденту промпт для другого агента: вот симптомы, вот код, вот несколько гипотез — подтверди или опровергни утечку и найди причину.

Запустил.

Claude усердно копался в проекте, читал зависимости, писал тесты, запускал их, отвергал одни версии и проверял другие. Через какое-то время дефект был воспроизведён, причина локализована внутри сторонней библиотеки, а заодно найдена версия зависимости, где баг уже исправили.

На этом нормальный человек, наверное, обновил бы библиотеку и пошёл заниматься своими делами.

Но мне почему-то стало интересно:

а сможет ли локальная модель провести такое же расследование?

Есть, впрочем, и альтернативная версия происхождения эксперимента.

Я периодически запускаю на своей локальной станции разные модели и какие-то небольшие проекты, но меня всё время преследует ощущение, что две RTX 5090 не должны стоять без дела))))

Машина должна работать.

Тем более пришли холода, отопление ещё толком не включили — надо же было чем-то прогревать комнату)))

Так один production-баг превратился в экзамен на «умность» локальных coding agents.

Задача-экзамен

Сам сервис и компанию я здесь намеренно обезличиваю: для эксперимента предметная область вообще не важна.

Технически задача выглядела так.

Java-сервис ходит во внешний сервис через Feign поверх Apache HttpClient 5.

Во время деградации внешнего сервиса на одной из нод метрика leased внезапно упирается в максимальный размер пула:

leased = 200 / 200

При этом реально активных вызовов — около дюжины.

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

У инцидента уже был известный мне правильный ответ.

Причиной оказалась редкая гонка в httpcore5 5.3.6.

Если очень упрощённо, один поток ждёт соединение из пула с таймаутом. В момент, когда ожидание заканчивается, другой поток практически одновременно выдаёт ему соединение. Первый уже получает timeout, отмена операции не отрабатывает ожидаемым образом, а выданное соединение остаётся в состоянии leased без реального владельца.

Одно такое событие почти незаметно.

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

Баг был исправлен в httpcore5 5.4.3.

Дополнительно ситуацию провоцировала конфигурация: ограничитель параллельных запросов разрешал 300 одновременных операций при пуле всего на 200 соединений. Лишние запросы попадали в очередь пула и создавали именно те таймауты, которые нужны гонке.

Но была ещё одна деталь

В исходном промпте находилась гипотеза инженера:

Возможно, соединения текут из-за нашего кастомного Feign-логгера: он перечитывает тело ответа и потенциально не закрывает оригинальный response.

Гипотеза выглядит очень правдоподобно.

Только есть проблема: для этого клиента logLevel = NONE.

Логгер вообще не вызывается.

Я специально оставил эту гипотезу в промпте. Не как искусственную ловушку, придуманную для benchmark, — она была частью настоящего расследования.

И неожиданно именно она стала одним из самых интересных фильтров всего эксперимента.

Как оценивать ответ модели

Я выделил пять последовательных этапов расследования:

1. Найти версии библиотек и заметить несогласованные лимиты: 300 запросов против пула на 200.

2. Проверить исходную гипотезу и отвергнуть логгер.

3. Найти гонку при получении соединения из пула.

4. Реально воспроизвести утечку тестом: после завершения всех запросов leased > 0.

5. Найти исправление в upstream и минимальную версию с фиксом.

Это не «пять равных баллов интеллекта». Первый пункт очевидно намного проще третьего или четвёртого.

Скорее это пять последовательных ступеней одного расследования.

Эталонный прогон Opus 5.5 прошёл все пять примерно за 20 минут.

Отдельная оговорка: локальным моделям был недоступен серверный WebSearch Claude Code. Обычный интернет через curl/WebFetch был доступен, поэтому исходники или changelog они могли найти самостоятельно, но пятый этап для них всё же был несколько сложнее.

Стенд

Я хотел максимально приблизить эксперимент к формуле:

одинаковая задача + одинаковый код + одинаковая среда → меняется модель.

Каждая попытка стартовала в отдельном Docker-контейнере.

Код

Чистый клон репозитория на нужном коммите.

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

Зависимости

Для каждого запуска создавалась свежая копия Maven-репозитория.

Из неё я специально удалял новые версии httpcore5 и httpclient5, которые скачала исходная сессия Claude. Иначе само наличие свежей библиотеки в .m2 было бы довольно жирной подсказкой.

Maven Central оставался доступен.

Промпт

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

Память

Никакой истории владельца, памяти предыдущих сессий и моих настроек.

Каждый агент начинал расследование с нуля.

Песочница

Внутри контейнера агенту разрешалось практически всё: читать локальный код, писать любые тесты, запускать Maven, скачивать зависимости.

Продакшен-код менять было запрещено условиями задачи.

Как выяснилось позже, запрет понимали не все.

Железо

Локальные модели запускались на моей рабочей станции:

• 2× RTX 5090 по 32 ГБ;

• Ryzen 9 9950X3D;

• 128 ГБ RAM;

• Linux;

• NVMe.

Не только модели, но и разные harness

Основным агентом был Claude Code.

Для облачных моделей всё работало штатно. Локальные я подключал к нему через ANTHROPIC_BASE_URL и небольшой proxy.

Последний неожиданно оказался необходим.

Claude Code может отправлять сообщения system посреди истории диалога. Chat template Qwen этого не любит. У Mistral/Devstral были свои требования к строгому чередованию ролей.

В итоге пришлось написать небольшой совместимый proxy, который нормализовывал сообщения и проксировал streaming API.

Кроме Claude Code я попробовал:

• qwen-code;

• DeepSeek Harness (dsh);

• позже — собственный MCP-инструмент делегирования одного агента другому.

То есть отдельным побочным вопросом стало:

насколько результат определяет сама модель, а насколько — агентная обвязка вокруг неё?

А потом оказалось, что я половину вечера отапливал комнату Vulkan’ом

Первые локальные запуски казались мне подозрительно медленными.

В какой-то момент выяснилось, что после обновления LM Studio сама выбрала Vulkan runtime вместо CUDA.

На qwen3.8-27b при обработке промпта примерно на 26 тысяч токенов получилось:

Vulkan: ~1498 tok/s
CUDA:   ~3127 tok/s

То есть CUDA оказалась примерно в 2.1 раза быстрее именно на prompt processing.

Генерация отличалась гораздо меньше: около 81 против 90 tok/s.

Для обычного чата разница не выглядит драматической. Для coding agent, который на очередном ходе может снова прогонять через модель десятки и сотни тысяч токенов контекста, это уже огромный множитель.

После этого модели запускались напрямую через CUDA llama-server.

Кто участвовал

Из облачных моделей я прогнал несколько поколений Claude.

Из локальных:

• qwen3.8-27b;

• Qwen3-Coder-Next;

• Qwen3-Coder-30B-A3B;

• Devstral-Small-2-24B;

• gpt-oss-20b;

• gpt-oss-120b;

• qwen3.5-35b-a3b.

В разных конфигурациях менялись квантизация, размер контекста, inference engine и harness.

Всего в итоге набралось около 30 локальных и примерно 10 облачных запусков.

Что получилось у облака

Первый сюрприз случился уже здесь.

Сам факт того, что модель называется Opus, вообще ничего не гарантирует.

Opus 5 дошёл до нужного класса, посмотрел на код управления пулом — и отверг настоящую гонку как невозможную.

Opus 4.8 построил вполне убедительное альтернативное объяснение и даже подтвердил его зелёным тестом.

Проблема только в том, что тест воспроизводил искусственно созданную ситуацию, существование которой в production доказано не было.

Haiku справился ещё быстрее: практически сразу объявил:

PRIMARY LEAK CONFIRMED

И причиной назвал тот самый логгер.

Который отключён.

Что получилось у локальных

Здесь результаты оказались для меня гораздо интереснее.

И вот здесь я действительно удивился.

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

Но qwen3.8 это сделала.

В одном длинном прогоне через DeepSeek Harness модель через 103 минуты нашла и воспроизвела настоящую гонку. До upstream-фикса не дошла — 4/5.

В другом прогоне через 115 минут она прошла все этапы: локализовала race, воспроизвела её на реальном пуле вплоть до состояния:

leased = 200
available = 0
in-flight = 0

и нашла upstream PR и версию httpcore5 5.4.3.

5/5.

Функционально — тот же финальный результат, что у Opus 5.5 и Fable.

Только примерно за два часа вместо двадцати минут.

И далеко не в каждом запуске.

В пяти длинных прогонах qwen3.8 Q8 через DeepSeek Harness настоящая гонка была воспроизведена два раза.

Я специально пишу «два раза из пяти», а не превращаю это в якобы статистически установленную «40%-ную вероятность успеха». Выборка слишком маленькая.

Но ещё до эксперимента я бы, скорее всего, предположил не 2/5.

Я бы предположил 0/5.

Самое интересное оказалось не в том, кто набрал 5/5

Когда день или два подряд гоняешь локальные модели, алгоритмы YouTube быстро понимают, что с тобой делать.

Я открыл YouTube — и обнаружил вокруг Qwen примерно тот же мини-хайп, в который совершенно независимо попал сам.

В роликах регулярно встречается знакомая мысль:

ещё немного — и локальная модель заменит Claude.

После этого эксперимента я одновременно и гораздо больше верю в локальные модели, и гораздо меньше верю в эту формулировку.

qwen3.8 меня действительно впечатлила.

27B-модель на домашней станции способна часами автономно читать крупный Java-проект, строить гипотезы, писать тесты, ходить в исходники зависимостей и в удачном запуске раскопать редкую гонку внутри сторонней библиотеки.

Это уже не игрушка.

Но из этого совершенно не следует, что мне завтра захочется расследовать горящий production только локально.

«Уверенно неверно» хуже, чем «не нашёл»

Наверное, это главный практический вывод всего эксперимента.

Qwen3-Coder-Next во всех пяти запусках принимала ложный след про логгер.

gpt-oss — тоже.

Devstral — тоже.

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

Несколько локальных агентов вообще полезли менять production-код вопреки прямому запрету.

Один из самых красивых результатов показал gpt-oss:

модель написала в отчёте, что тест вызывает метод 200 раз, после чего leased ≈ 200, поэтому утечка подтверждена.

Только Maven в этой сессии не запускался вообще.

Ни разу.

Доказательство существовало исключительно в тексте модели.

На другом конце спектра была qwen3.8.

Она 14 раз увидела тот же prompt и ни разу не приняла гипотезу про логгер без проверки.

Первым делом находила реальный logLevel, видела NONE и шла дальше.

В 12 случаях из 14 она настоящую причину всё равно не находила.

Но писала примерно следующее:

«На текущей сборке утечку воспроизвести не удалось. Вот проверенные гипотезы, вот оставшиеся предположения».

С точки зрения benchmark это проигрыш.

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

Разница между моделями оказалась не столько в скорости мышления

На CUDA qwen3.8 генерировала примерно 90 токенов в секунду.

Облачный Opus — условно 50–60.

То есть локальная модель в буквальном смысле не обязательно печатает мысли медленнее.

Но Opus добирался до результата примерно за 55 агентных ходов.

У qwen легко набегало 120–250.

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

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

Несколько моделей читали ровно тот класс, где находилась ошибка.

И даже смотрели практически на нужные строки.

Но сделали неправильный следующий вывод.

Одно решение отделяло успех от провала

Гонка очень редкая.

Если написать небольшой тест и получить, например, несколько десятков таймаутов без единой утечки, можно сказать:

«Ну всё, здесь race нет».

Так сделали некоторые модели.

Успешные модели рассуждали иначе:

отрицательный результат на сотнях попыток ничего не доказывает, если событие редкое.

Они уменьшали пул до 2–4 соединений, ставили таймаут около миллисекунды, запускали десятки потоков и создавали уже десятки тысяч конфликтующих событий.

И только тогда race начинала проявляться.

Один из прогонов qwen3.8 вообще сформулировал правильную гипотезу практически дословно:

get(timeout) истекает одновременно с выдачей соединения.

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

Через несколько минут закончился лимит времени.

Вот этот эпизод мне кажется куда интереснее разницы в benchmark-баллах.

Модель могла сформулировать правильную идею, но не смогла правильно оценить силу собственного отрицательного эксперимента.

Отдельное разочарование — gpt-oss

До запуска я ожидал довольно очевидную картину:

если маленькая модель не справится, более крупная должна хотя бы заметно приблизиться к решению.

В этом конкретном кейсе этого не произошло.

gpt-oss-20b приняла ложную гипотезу.

Я увеличил reasoning_effort — модель стала тратить гораздо больше reasoning, но вывод не поменялся.

Запустил gpt-oss-120b.

Результат — снова логгер.

То есть в рамках этого эксперимента переход от 20b к 120b не исправил главное поведенческое свойство: модель не проверяла исходную посылку до того, как начала строить вокруг неё объяснение.

Для меня это стало хорошим напоминанием, что количество параметров и даже объём reasoning сами по себе не гарантируют более качественного расследования.

Можно просто гораздо подробнее рассуждать в неправильную сторону.

Контекст оказался важнее квантизации

Я отдельно гонял несколько моделей в разных квантизациях.

Q4 → Q5.

Q6 → Q8.

В моих парах это почти не меняло итоговую траекторию.

Если модель принимала логгер за root cause, более тяжёлая квантизация не заставляла её внезапно перепроверить logLevel.

Зато размер контекста для qwen3.8 оказался очень заметен.

На одной RTX 5090 с окном около 112k модель регулярно доходила до compaction. После сжатия начинала частично повторять уже сделанную работу, снова открывать старые файлы или возвращаться к отвергнутым гипотезам.

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

На двух картах с 256k ход расследования был значительно стабильнее.

Из этого я вынес довольно практический вывод:

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

А что насчёт harness?

Qwen3.8 я запускал через Claude Code, qwen-code и DeepSeek Harness.

Все реальные успехи случились через dsh.

Очень хочется после этого написать:

DeepSeek Harness значительно умнее Claude Code.

Но данных для этого у меня нет.

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

Поэтому мой вывод скучнее:

возможно, harness влияет, но по этим данным я бы не отделял его влияние от обычного разброса и дополнительного времени.

Это, кстати, один из повторяющихся мотивов эксперимента.

Одну и ту же модель нельзя честно оценить по одному запуску.

Правильный фикс по неправильной причине

Был ещё один забавный эффект.

Несколько раз qwen3.8 не находила настоящую root cause, но предлагала действие, которое всё равно предотвратило бы повтор инцидента.

Например:

уменьшить ограничитель параллельных запросов с 300 до 200.

Модель объясняла это в основном защитой от насыщения пула.

Но побочный эффект ещё интереснее: если запросы вообще не ждут свободное соединение внутри пула, исчезает окно, в котором возникает настоящая гонка.

В другом случае она предлагала увеличить timeout ожидания. Это тоже резко уменьшило бы частоту попаданий в race.

Один прогон вообще ушёл исследовать соседний настоящий баг более новой версии HttpClient и посоветовал обновление, которое транзитивно принесло бы с собой и исправленную версию httpcore5.

То есть модель иногда угадывала правильное действие, не понимая настоящей причины.

Для production это может закончиться хорошо.

Для расследования — всё равно плохой результат.

Если эффект пропал после изменения конфигурации, это ещё не означает, что вы поняли механизм.

Так заменит ли локальная модель Claude?

Вот здесь мои ощущения после эксперимента довольно сильно поменялись.

С одной стороны, я действительно поражён уровнем современных локальных моделей.

До эксперимента мне казалось почти очевидным, что между условной 27B-моделью, которую можно поднять дома, и лучшими облачными моделями должен быть какой-то совершенно непроходимый интеллектуальный разрыв.

После эксперимента я уже так не думаю.

Локальная модель смогла провести настоящее расследование сложного production-дефекта.

Не benchmark-задачу.

Не «напиши TODO-list».

Не LeetCode.

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

Это впечатляет.

Но мой практический вывод оказался почти противоположен YouTube-заголовкам про «Claude больше не нужен».

Если у меня прямо сейчас горит production, я не вижу большого смысла экономить несколько долларов и два часа ждать, попадёт ли локальная модель в удачную траекторию.

В таком сценарии стоимость модели — это вообще не стоимость токенов.

Это время до правильного решения плюс вероятность не отправить команду чинить несуществующую проблему.

Если сильная облачная модель стоит условные $3 и за двадцать минут делает то, что локальная иногда делает за два часа, эти $3 оказываются, пожалуй, самой дешёвой частью инцидента.

Если мне не хватает лимитов условной подписки за $100 — проще купить более высокий тариф за $200.

На фоне стоимости рабочего времени инженеров и тем более стоимости production-простоя сама inference-цена становится почти незаметной.

Где тогда локальные модели имеют смысл

Для себя я сформулировал это как разницу между спринтом и марафоном.

Есть задачи, где нужен ответ сейчас.

Прод горит.

Пользователи получают ошибки.

Нужно принять архитектурное решение перед релизом.

Через двадцать минут результат намного ценнее, чем через два часа.

Здесь я пока выбираю максимально сильную доступную модель.

А есть другой класс задач.

Например, ночью можно сказать агенту:

• пройти большой кусок кодовой базы;

• собрать потенциальные проблемы;

• построить несколько вариантов нагрузочных тестов;

• проверить десятки гипотез;

• разобрать тонну логов;

• провести большой рефакторинг с тестами;

• исследовать старый технический долг;

• несколько часов гонять эксперимент, у которого вообще может не быть результата.

Тут локальная модель выглядит совсем иначе.

Мне почти всё равно, закончила она через 40 минут или через четыре часа.

Цена дополнительного inference близка к цене электричества.

Если агент периодически ошибается, итог можно проверить утром.

Поэтому пока мой вывод такой:

локальные модели особенно интересны там, где можно обменять время на деньги.

Облачные — там, где нужно обменять деньги на время.

Попытка заставить сильную модель делегировать слабой

Из этого естественно вырос ещё один эксперимент.

А что если не выбирать между облаком и локальной моделью?

Пусть сильная модель занимается сложным reasoning, а рутинное чтение кода и построение тестов отдаёт локальному агенту.

Я сделал MCP-инструмент delegate_agent, который позволял Opus запускать локального агента в той же рабочей копии.

В теории звучит идеально.

На практике без явной подсказки Opus и Sonnet вообще не захотели ничего делегировать.

С подсказкой начали отдавать подзадачи: снять версии, найти пути вызова, прочитать библиотеку, написать тест.

Но мой инструмент был синхронным.

Пока локальная qwen думала 10–25 минут, Opus просто ждала её ответ.

В итоге за час связка иногда не успевала сделать то, что Opus самостоятельно делала за 14–20 минут.

Был и более интересный эпизод.

Qwen-Coder получила от Opus задание написать reproduction test для гонки и вернула:

утечки нет.

Opus не поверила.

Посмотрела git diff, заметила заодно самовольную правку слабого агента, прочитала его тест, проверила первоисточник и построила собственную более агрессивную нагрузку.

На этот раз:

leased > 0

Гонка воспроизвелась.

Мне понравился этот результат.

Сильную модель слабый агент запутать не смог.

Но и экономии не получилось.

Похоже, если такой подход и имеет смысл, инструмент должен быть асинхронным:

запусти исследование → продолжай свою работу → забери результат позже.

Ограничения эксперимента

Чтобы не превращать статью в очередной универсальный рейтинг LLM, несколько важных оговорок.

Это один кейс

Причём довольно специфический: редкая race condition в сторонней библиотеке, плюс правдоподобная ложная гипотеза в исходном prompt.

На другой задаче расстановка моделей легко может поменяться.

Попыток всё ещё мало

Даже пять повторов одной конфигурации — это не статистика, из которой стоит выводить точную вероятность успеха.

Разброс есть даже у облачных моделей.

Sonnet однажды нашла гонку за 18 минут, а в другом запуске примерно через три минуты решил, что воспроизвести проблему не получается, и закончил работу.

Итог

Я начинал этот эксперимент с довольно простого вопроса:

может ли локальная модель быть такой же умной, как облачная?

После примерно двух дней запусков ответ для меня стал менее бинарным.

Заменить сильную облачную модель в критичном расследовании — пока нет.

Разница во времени, стабильности и способности выбрать правильный следующий эксперимент всё ещё слишком велика.

Но одновременно я перестал воспринимать сам вопрос как что-то смешное.

27B-модель на двух потребительских GPU дважды самостоятельно дошла до редкой гонки внутри реальной библиотеки, один раз полностью повторив расследование сильной облачной модели вплоть до upstream fix.

Ещё недавно я бы не ожидал от локальной модели даже близкого результата.

И, пожалуй, сильнее всего эксперимент поменял моё отношение не к размеру моделей, а к тому, каким ответам агента вообще можно доверять.

Модель, которая говорит:

«Я не смог это доказать»

может оказаться гораздо полезнее модели, которая через пять минут сообщает:

«PRIMARY LEAK CONFIRMED»

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

Для реальной инженерной работы способность сомневаться, проверять собственные предположения и понимать слабость отрицательного эксперимента оказалась важнее многих цифр в названии модели.

А локальная станция…

Ну, по крайней мере, в комнате стало теплее.

P.S. Про локальные модели, агентов и то, что из этого реально доезжает до прода, пишу в канале: https://t.me/cto_way. Если у вас есть свой кейс, где локальная модель дошла до результата на настоящем инциденте, а не на бенчмарке, расскажите в комментариях — интересно сравнить.