AI - скрытые угрозы.

Два поста для затравки:
https://t.me/orgprog/465
и
https://t.me/seeallochnaya/3513

Первый - что там, где раньше "кожаные мешки" старались не писать "лишний" код, т.к. это дорого по затраченному времени.
А сейчас появляется соблазн это делать, т.к. AI пишет код существенно быстрее.
Далее если логически продолжить - появляется соблазн меньше проверять код, больше доверять этот процесс LLM, чтобы не стать "слабым звеном" в цикле разработки.
И это мы говорим про профессиональных разработчиков. А ведь есть еще PO, менеджеры, ... ставшие на тропу вайб-кодинга.

Второй пост о том, что новая модель Anthropic Mythos сильно круче предыдущих.
Настолько круче, что ее даже не стали выпускать в открытый доступ, т.к. она слишком хорошо ищет уязвимости.
Доступ выдадут ограниченному числу компаний https://t.me/ai_machinelearning_big_data/9829.

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

P.S. И это я не рассматриваю вариант, что модель выпустят из песочницы и дадут рычаги влияния на реальный мир https://t.me/lovely_it_hell/651

#ai

Когда я изучал тарифы на доступ к LLM, меня удивила явная асимметрия.

С одной стороны за 18 баксов в месяц можно получить условный безлимит.
Я про оплату 200$ за год.
А безлимит условный, потому что внутри дня и за неделю все же есть лимиты.
Тут кстати прикольные флешбеки.
В детстве я ждал часа Х, чтобы сходить в ВУЗ поработать за компом.
А позже когда был общий комп на двоих с братом - тоже ждал своего времени.
А сейчас многие ждут, когда сбросится пятичасовой лимит Claude Code.

Но я отвлекся.
А с другой стороны - если платить за токены по API, то выходит на порядок дороже, те же 18$ можно сжечь за пару часов.
Это по ценам openrouter.ai. А если его прикрою и\или приходится пользоваться русскими проксями - еще +20%.

Вопрос - это же не выгодно провайдерам LLM моделей?

А вот и ответ https://vc.ru/ai/2851931-obkhod-blokirovki-anthropic-dlya-storonnikh-instrumentov
Anthropic уже начали блочить использование OAuth доступа (безлимитного) в сторонних агентах типа OpenClaw.
Пока это можно обойти.
Но тенденция понятная. Им скоро на биржу выходить, доходность повышать надо.

P.S. Да бывают бесплатные модели, они как правило появляются у всех в одно и тоже время - openrouter, внутри самих агентов.
Но это по сути бета-тест + рекламная акция. И длится она пару дней\недель\максимум месяцев.

#ai

Есть радикальный подход к внедрению AI в разработку.
Звучит он так - считайте, что код на языках общего назначения превращается в ассемблер.
Люди его писать и читать будут только в исключительных случаях, генерировать его будет машина.

Лично я на сегодня (!) этот подход считаю слишком оптимистичным. Или пессимистичным, с какой стороны смотреть)
Хотя, может быть в будущем. Посмотрим.

Но вопрос затрагивается интересный. Весь ли код надо писать самому?
Тут ответ видится очевидным - нет.
Весь ли код нужно построчно проверять после того, как его сгенерил AI - кажется тоже нет.

Есть же у нас generated код. DTO-шки для OpenAPI, например.
Наверное, человек бы написал его лучше. Компактнее, функциональнее, чище.
Но много ли желающих лезть туда руками? Кажется, даже мысли не возникает.
Потому что мы доверяем генератору.

AI конечно не детерминирован, в отличие от hardcoded генератора. Но модели сильно выросли в качестве, и у нас есть тесты.
Соответственно, часть кода приложения также можно сделать ai generated: пометить какой-нибудь аннотацией (или комментарием) и генерировать только с помощью AI.

Какой именно код?

Весь вспомогательный код, помогающий выполнять бизнес-логику приложения.
Тот, который по-хорошему надо бы переиспользовать, но подходящей библиотеки нет. Или она тянет за собой лишние зависимости. Или она заброшена автором. Или библиотека есть, но ее бы немного доработать.
И этот код наверняка есть в куче репозиториев на GitHub, но искать лень.
Ага, значит о нем знает LLM, и значит она его будет хорошо генерировать.

И конечно нужны тесты. Тесты может написать модель, но критерии нужно задавать\проверять самому.
И стиль для тестов задавать - какие библиотеки используем, гранулярность, что тестируем, что не тестируем.

А какой процент кода сервиса в итоге станет AI generated - посмотрим)

#ai

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

Поэтому неудивительно, что появляется вот такая книга https://www.piter.com/collection/new/product/patterny-coding-interview-podgotovka-k-slozhnomu-tehnicheskomu-intervyu?utm_campaign=177670675710 )))

P.S. не читал, но по оглавлению можно сказать, что там паттерны для решения задач с leetcode

#patterns

Меня радует, как развивается Spring AI.

Если посмотреть на основной функционал - https://docs.spring.io/spring-ai/reference/2.0-SNAPSHOT/index.html - то мы видим поддержку:
0) формирование промта (шаблон, роли)
1) tools calling
2) RAG
3) Chat History
4) MCP
5) structured output

Тут конечно возникает вопрос - это вчерашний день, база, где же тут развитие?

А развитие вот тут: https://github.com/spring-ai-community/spring-ai-agent-utils
Это еще не часть фреймворка, но авторы кода из Spring-а. И есть цикл статей в блоке Spring https://spring.io/blog/2026/04/15/spring-ai-session-management
Ссылка на последнюю статью, т.к. только в ней есть кросс-ссылки на всю серию.

Что добавили:
1) skills
2) субагентов
3) долговременную память (!)
4) работу с сессиями включая их сжатие с разными стратегиями (плавающее окно, суммаризация (!))
5) кросс-агентское взаимодействие (A2A протокол)
6) контроль процесса выполнения через ToDoWrite (формируем список задач и помечаем прогресс)
7) и даже тула AskUserQuestion

В общем авторы все "слизали" у Claude, но это очень даже хорошо, т.к. Claude сейчас во много формирует отрасль.

Единственный потенциальный минус - это preview библиотеки, следовательно, API будет меняться. Но с другой стороны - миграции кода сейчас делать проще)))
А практическая цель создания такого "велосипедного" агента как минимум следующая - собрав "свой Claude Code" можно лучше понять как работают современные агенты.

#ai

3 способа как один разработчик может работать "одновременно" над несколькими фичами в одном git репозитории.

Для начала, на всякий случай - зачем это нужно?

1) Делаем фичу - прилетел баг, нужно быстро поправить -> в отдельной ветке и вернуться к исходной фиче.
2) Делаем фичу, на пол-пути понимаем, что сейчас довести до конца ее не получается, нужно переключиться на другую.
3) Делаем фичу, нужно поизучать другую ветку локально.
4) Ну и конечно же AI, время такое: кодим c AI, агент умеет параллелить выполнение каких-то простых рефактирингов (а многие уже умеют).

Какие есть варианты, от простого к сложному:

1) checkout.
Если говорить о параллельной работе, то тут только минусы.
Что произойдет с незакомиченными изменениями при переключении?
Варианты такие:

а) они попадут в новую ветку, если зафиксированное в git состояние изменяемого файла одинаковое в обоих ветках.
Или если создается новая ветка git checkout -b <branch>, тогда состояние по определению одинаковое.
В последнем случае это полезный хак - когда по ошибке начал кодить в master. Это наверное главный плюс, но он не относится к параллельной работе над фичами.
Но таким же образом можно по ошибке пронести в ветку лишние изменения.

б) если зафиксированное состояние изменяемого файла отличается в ветках - переключение по checkout не произойдет, изменения придется явно commit-ить или откатывать

в) при использовании git checkout -f <branch> (force) незакоммиченные изменения будут потеряны.

Итого - риск потерять данные, риск закоммитить лишнее. Плюс т.к. все файлы в одной папке - запущенный процесс ОС может блокировать checkout.
Применять имеет смысл если дошел до какой-то логической точки в текущей фиче и надолго переключаешься на новую.

2) stash.
В этом случае diff изменений попадает в локальный стек, работающий по принципу FIFO.
Команды git stash pop и git stash apply.
Вроде как удобно, но по своему опыту знаю, что изменения легко в стеке забыть. Это собственно главный минус, нивелируется при кратковременном переключении.
Плюс - параллельная работа возможна, переключение быстрое, места на диске занимает мало.

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

3) worktree.
Здесь идея в том, что рабочие файлы каждой ветки хранятся в отдельной папке.
Корневая папка проекта, он же рабочий каталог - всего лишь одна из копий.
А в .git/worktrees хранятся другие копии.
В теории можно не создавать исходники в корневой папке, если вызвать git clone --bare <repository-url>.
Обычно эту команду используют на серверах типа GitHub, Bitbucket, но также полезно и для работы с несколькими worktree.

Команда создания нового дерева для существующей ветки: git worktree add ../<folder> <branch>
и удаления: git worktree remove ../<folder>

Тут может возникнуть вопрос - как git понимает, с какой копией он работает в данный момент?
Ответ: по текущему пути и по наличию папки .git внутри каждой копии.

Самое интересное - многие агенты, а точнее те, кто умеют параллельно работать - используют worktree.

Плюсы: каждая копия изолирована от других, случайно пронести лишнее сложно, невозможно заблокировать файлы из другой ветки (правда остается проблема с открытыми портами).
Минусы: требуется больше места на диске. Но если не хранить бинари в git, а этого делать не нужно, то не критично.
Ну и нужно привыкнуть, что актуальные исходники не лежат в корне проекта.

Итог - применять имеет смысл для AI разработки и для параллельной работы руками.

#git #ai

Ты что такое или как AI ревьювит код?

Изучаю сейчас плагин superpowers, который включает в себя много чего интересного, и в т.ч. и код-ревью.
Вижу два интересных момента.

Первый. Модель постоянно берет куски нового кода и запускает их с каким-то параметрами, например, с краевыми случаями.
Для начала куски метода, потом методы целиком.
Это явно плюс в карму AI, т.к. живому человеку это делать долго и дорого.
Кто-то так делал вообще?)
Надо отметить, что в Java это еще и сложнее сделать, чем в том же Python или JS, хотя подвижки есть - https://t.me/javaKotlinDevOps/412
Тут видится хорошая область, где AI ревьювер может дополнить человека.

Для демонстрации второго момента приведу кусок кода - это лог выполнения скрипта, который агент прогонял на этапе ревью. Код python, но он простой:

{"command":"python -c \"
import pandas as pd
import numpy as np

# Probe: does max_pos + 1 in rng.integers allow the window to exceed bounds?
# n = 10, duration = 3, max_pos = 7
# rng.integers(0, max_pos + 1) -> [0, 7] inclusive
# pos=7: index[7], window is [index[7], index[7]+3min)
# If index has exactly 10 rows (0..9), this is index[7], index[8], index[9] -> 3 rows OK
# pos=8: This would only happen if max_pos=8, which requires n-duration=8, so n=11 - fine
print('Boundary logic: max_pos = n - duration_minutes')
print('rng.integers(0, max_pos+1) is [0, max_pos] inclusive')
print('At max_pos, window covers indices [max_pos..max_pos+duration-1], which is valid')
print()

\"
","description":"Verify off-by-one and boundary correctness in random placement logic"},

На первый взгляд бред какой-то. Код ничего не делает, только печатает очевидные вещи, частично как комментарии, частично через print.
Но если подумать - похоже модель проверяет логику на отсутствие ошибки "ошибки на единицу".
Проговаривая ее для себя. Ну и возможно для меня, но видится в первую очередь для себя.
Т.к. это все попадает в историю диалога с LLM и далее в ее контекст, влияющие на результат выполнения последующих запросов.
С таким проговариванием человек справляется успешно, но радует, что модель тоже, хоть и вот так, странненько.

P.S. Ошибка между прочим известная, не у каждой ошибки своя статья в wikipedia есть https://ru.wikipedia.org/wiki/Ошибка_на_единицу

P.P.S. Но импорты явно лишние)

P.P.P.S. Риски самому перестать думать возрастают)))

#ai #code-review

MCP - новая проблема.

Есть такой стандарт для стандартизированного добавления кастомных тулов - MCP.
Он позволяет разрабатывать тулы на любом языке и выставлять их наружу, для использования агентом, по протоколу JSON-RPS через http (независимый удаленный сервис) или stdio (дочерний процесс).
Вроде бы крутая штука. Если бы не детали реализации)

Главная проблема такая - по стандарту MCP сервер выставляет метод tools/list, возвращающий список тулов в формате name, description, inputSchema.
В чем проблема?
Предположим мы выставляем в MCP API какой-то серьезной системы. Например, Atlassian. Сколько там методов? А какого размера у них inputSchema?
А контекст не бесконечен, более того, после заполнения 50% контекста качество ответов ухудшается.
Т.е. подключив пару тяжелых MCP серверов есть шанс сразу же, с первого запроса, снизить качество работы LLM. А MCP могут и не пригодиться в данном сеансе работы.

Вторая проблема - агент подключается ко всем MCP при старте, вызывая ряд методов (initialize, tools/list) что требует времени.

Слышал по этому поводу мнения, что MCP нам вообще не нужны.
Я бы сказал - такие MCP - да, не нужны. А в целом идея хорошая, не все скилами можно реализовать из-за сложности и вопросов безопасности.

Что делать?

1) несколько профилей агента, с разным набором MCP серверов. Возможно даже lite версию вообще без MCP (Claude Code через --strict-mcp-config --mcp-config '{}', Gemini\Qwen Code через --allowed-mcp-server-names '{}').

2) переписать MCP на skill если это простая прокси к внешнему API. Скил может включать в себя Python скрипты. Агенты такие скилы неплохо пишут.
Скилы сделаны "по уму", там в контекст по умолчанию выставляется только name и description, содержимое SKILL.md и другие файлы добавляются по мере необходимости.
Этап подключения для скилов отсутствует, это просто специализированный промт.

3) lazy load описаний и схем тулов, сделанный на уровне агента. Claude Code, видимо по принципу "Я тебя породил, ..." реализовал это первым https://vc.ru/ai/2864901-claude-code-i-mcp-lazy-loading-uluchshaet-ai-agentov.
Итоги, цитата:

Контекст при старте: экономия до 95%. В одном реальном кейсе — с 51 000 токенов до 8 500.
Точность на Opus 4: с 49% до 74% на MCP-бенчмарках с большими библиотеками инструментов.
Точность на Opus 4.5: с 79,5% до 88,1%.
Максимальное описание инструмента: ограничено 2 КБ

Причем lazy load включается тоже lazy - когда описания MCP tools начинают занимать более 10% контекстного окна. Красиво)

Причем есть предложение дальнейших оптимизаций: https://github.com/anthropics/claude-code/issues/44536
Включая:
а) грузить description скилов тоже лениво. Тут видится противоречие, по стандарту именно description содержит информацию когда подгружать скил. Имя конечно тоже должно быть адекватным, но оно может быть очень коротким.
С другой стороны, если имена нескольких скилов лексически\семантически похожи - ленивая загрузка будет работать, т.к. агент загрузит оба скила и далее уже по описанию выберет правильный.
б) ленивое подключение к MCP - тут понятно
в) профили агентов - это стандартизация решения номер №1. Сейчас это несколько разных папок с агентами, а должны быть - несколько файлов профиля.
г) загрузка тулов\скилов по условию (только при написании тестов, например)
д) динамическая выгрузка
Ну в общем полноценное управление памятью, т.е контекстом)

Есть похожие issues и для других агентов, пока в статусе Open
https://github.com/openai/codex/issues/2335
https://github.com/anomalyco/opencode/issues/17482

4) решение на уровне стандарта MCP. Вот тут все плохо, идут обсуждения, но конкретных предложений нет.
Вот предложение https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1576
Вот еще одно https://github.com/orgs/modelcontextprotocol/discussions/532
Но до реализации дело не дошло.

Вывод - AI агенты активно развиваются.

#ai #ai_agents #mcp #ai_agent_context_management

В продолжение темы MCP - вот пример переписывания MCP тулов для запуска браузера на скилах и Node.js скриптах https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp

А все почему? Цитата:

Playwright MCP has 21 tools using 13.7k tokens (6.8% of Claude's context). Chrome DevTools MCP has 26 tools using 18.0k tokens (9.0%). That many tools will confuse your agent, especially when combined with other MCP servers and built-in tools.

При этом Claude по большей части эту проблему пофиксили.

P.S. Что интересно - многие агенты написаны на Node.js, и они за собой тащат Node.js через скилы. Под соусом - ну у вас же точно установлен Node.js.

#ai #mcp

Заменит ли AI разработчика?

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

Я выделил следующие навыки:
1) логическое мышление, нахождение причинно-следственных связей
2) алгоритмическое мышление (а-ка задачки с leetcode)
3) абстрактное мышление, проектирование архитектуры
4) анализ, решение проблем, работа с неопределенностью
5) базовые практики - shell, git, DevOps, Docker\k8s, отладка, профилирование, телеметрия, ...
6) глубокое знание своего стека (Java, Android, JS...)
7) опыт, знание паттернов (паттерны - это по сути концентрированный опыт)
8) работа с заказчиком, софт-скилы

Что становится ненужным с внедрением AI?
Кажется, что ничего)

В теории можно было бы выкинуть 5-7, но есть нюанс.
Если мы считаем, что модель по итогам brainstorm-а с пользователем всегда сгенерирует 100% полные требования, по которым в свою очередь создаст 100% правильный код с 100% тестовым покрытием - то да, выкидываем.
Это реально? Нет.
LLM - повторяет существующий код, на котором обучалась.
А в существующих решениях 100% правильного нет, т.к. задачи и подходы у всех разные.
А если в решении будут ошибки, то чтобы понять, что не так, как раз и требуется опыт, знание стека и практик.
А опыт нужно где-то получить, но это уже отдельный вопрос.

Упадет ли важность опыта, знания стека и практик? Да, как минимум потому, что на простых атомарных задачах AI будет допускать все меньше ошибок. Не не исчезнет.

Сможет ли владелец продукта писать код?
Ну если он владеет логическим, алгоритмическим и абстрактным мышлением - да, до какого-то уровня. Собственно до уровня, когда нужно будет "залезть в код".
А ещё есть мнение (Алан Кей, создатель ООП и языка SmallTalk) - что этими качествами обладают 5% населения https://tinlizzie.org/IA/index.php/End-User_Programming_by_Alan_Kay_(1991)

Нужно ли будет столько разработчиков? Вот тут вопрос, да...
Но очевидно, что хорошие разработчики будут нужны.

P.S. И с увеличением количества кода резко увеличивается важность навыка работы с неопределенностью. Не построчно же весь AI код ревьювить)

#ai

distroless образы Docker.

Что такое Docker - это Linux...
Но нет, на самом деле.
Linux-а внутри может не быть.

Это легко проверить, сделав образ

from scratch

Но что полезного в таком образе?

Ок, добавим Java.
Но на самом деле для работы реальных сервисов нужно чуть больше Linux обвязки.
Пользователи, временные настройки, папка /tmp, корневые сертификаты (если нет SSL origination на egress).
Вот для таких случаев и в то же время для упрощения реализации требований по безопасности придумали distroless образы.
Грубо говоря это что-то среднее между scratch и обычным образом. Есть конфиги и структура папок, но практически нет исполняемых файлов. И библиотек C-ных по минимуму.
Детальнее тут https://habr.com/ru/companies/flant/articles/822427/

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

Минусы тоже есть.
Для начала - логи локальные никуда не денутся. Stdout/stderr перехватывается драйвером Docker/k8s и сохраняется на хост-сервере.
Будем работать команда

docker cp

ей shell не нужен.
Но изучать файловую систему контейнера так будет сложно.
А уж запустить внутри образа, скажем, curl для проверки локальных endpoints так просто не получится. Ну и из бизнесового сервиса shell команду конечно же не запустишь.

Какие варианты?

1) классический: "хорошо делай - хорошо будет") В смысле пиши достаточно подробные логи, сделай возможность управлять уровнем логирования, отбрасывай метрики и трейсы, отдавай подробные healthcheck. И будет счастье. Или нет)

2) держать рядом нормальный образ сервиса - т.е делать два образа каждый раз. И иметь возможность быстро накатить отладочный образ на ПРОМ. Тур вставк встает вопрос - можно ли итоги тестирования одного образа автоматически применить ко второму? Или тесты гонять дважды? Не хотелось бы.

3) debug ephemeral sidecars. Отличаются от обычных тем, что могут быть добавлены к поду в любой момент и исчезают после его рестарта. Запускаются командой
kubectl debug pod/mypod
-it
--target=myapp
--image=busybox

Ещё надо бы включить в Deployment sharing процессов, чтобы работала ps.

shareProcessNamespace: true

Ну и согласовать все это с безопасниками. Детальнее https://habr.com/ru/companies/timeweb/articles/720510/
Кажется, хороший вариант как раз для distroless контейнеров.

#docker #security

Куда пропала дешевая память?

Можно даже расширить вопрос - и дешевые SSD?
Про видеокарты все понятно, сначала крипта, потом AI. Геймерам остается только покупать приставки. Учитывая их железо не удивлюсь, если ими в ноль торгуют, отбивая деньги на играх.

Но вернемся к разработке.
Ответ легко найти в интернете - виноват AI.
Первая связь, которая приходит на ум - видеокартам нужна память. А для видеопамяти хотя и используется специальный тип памяти HBM, но эта память, как и ОЗУ, и чипы в SSD часто производят на одних и тех же фабриках. И понятно что сейчас там фокус на память для видеокарт.

Давайте прикинем, сколько памяти нужно для развёртывания LLM модели?

Модель - это набор векторов, вектор - набор float чисел. Количество параметров модели = количеству этих чисел.
Каждому сгенерированному токену (это несколько символов) тоже соответствует вектор, эти вектора сохраняются в KV кэше чтобы не пересчитывать заново.
Сразу важная ремарка - скорость ответа LLM критична к скорости работы с памятью. Поэтому целевой кейс - модель и ее KV кэш находятся в памяти видеокарты, т.к. она самая быстрая.
Еще момент - кэш сессионный, нельзя смешивать данные разных пользователей.
Т.е получаем формулу:

V = Vllm + Vkv * sessions + Vsys

Vllm - объем памяти для модели,
Vkv - для кэша,
sessions - число одновременных сессий,
Vsys - системная память, как некий аналог - в JVM приложении выделяется фиксированная область памяти для JIT компилятора. Можно перенебречь, это единицы Гб.

По умолчанию 2 байта на число.
Тогда для к примеру Qwen-3-Coder-Next со 80B параметров

Vllm = params x bytes = 80 x 10^9 × 2 = 160 Гб

где params - количество параметров модели
bytes - размерность одного числа, 2 байта.

160 Гб - уже неплохо. Локально не запустим)

Перейдем к KV кэшу.

Типовое число одновременных сессий зависит от мощности GPU. Цель - максимальная утилизация мощности GPU. Ограничение - размер памяти. Пока будем считать для одной сессии.

Вторая важная переменная - размер контекстного окна модели. Это и есть размер кэша. У Qwen - 256k.
К слову, максимум на данный момент - 1 млн. Тут надо понимать, что декларируемый размер окна - теоретический максимум и частично маркетинг. Как говорится - должен, но не обязан)
Для чатов и для code агентов с условно безлимитными подписками провайдеру не выгодно давать полное окно в 1 млн токенов, и скоро станет ясно почему. Хотя при оплате за токены получить его можно.
Поэтому наш пример можно считать типовым.

Далее KV - это key и value. Почему кстати key и value - почему не просто вектор? Модель при генерации очередного токена использует все ранее сгенерированные токены. key определяет вес (важность) данных в старом токене для генерации нового, а value - это собственно сами данные.
Этот механизм называется Attention.

А общая формула для кэша такая:

Vkv = sessions × context х размер токена = sessions × context × ( 2 × bytes × layers х hidden )

layers и hidden - число слоев и размер вектора - это представление символа внутри движка инференса. Слой можно представить как этап конвейера генерации символов. Примерно можно считать, что первые этапы отвечают за лексику и синтаксис, последние - за смысл.
Числа отличаются от модели к модели, значения для Qwen Coder - 48 и 2048 соответственно.
bytes такой же, как и для модели - 2 байта, float.
Итого получаем:

Vkv = 1 х 256 000 х 2 × 2 × 2048 × 48 =  100 Гб

Тут уже прикольно, что токен "кот" в LLM превращается в 400kB. gif-ки с котиками они там что ли хранят (шутка)

Итого 260 Гб памяти на одну клиентскую сессию на не самой сильной модели.
Ага, вот куда вся память делась!)

Попросил ты такой перевести LLM страничку на русский и сожрал 260 Гб...

Тут может возникнуть вопрос - а как оно вообще работает?)
Условный Claude Opus вообще ни в одну видеокарту не влезет. Там по оценке 5 триллионов параметров, т.е. в 50 раз больше, и пропорционально увеличившийся KV кэш.

Ответ: оптимизации. Кажется среди AI инженеров сейчас много хороших оптимизаторов)

Примеры.

Квантование - т.е. снижение размерности коэффициентов модели и кэша. Чаще используют с коэффициентами модели. Распространённый кейс: использование int4 - 4-битный int вместо 2-байтного float. Это уменьшает размер модели в нашем примере в 160 * 0.5/2 = 40 Гбайт.

По KV кэшу начнём с ленивого выделения памяти для кэша. А это значит в расчетах можно ориентироваться на средний размер контекстного окна, а не максимальный.
По разработке я бы оценил его в 64k. У чата сильно меньше, но мы же оцениваем Qwen Coder.

Итого 100 х (64 / 256) = 25 Гб.

Ещё у Qwen-а есть 2 оптимизации: Grouped Query Attention и гибридная архитектура Attention.
Если вкратце - первая позволяет переиспользовать значения кэша при генерации разных символов, уменьшая требуемый объём памяти в 8 раз для нашего случая.
Вторая - заменяет ряд layers на перезаписываемую матрицу постоянного размера, и как ни странно это не сильно ухудшает качество ответа, но уменьшает число слоев в 4 раза в нашем случае.

Итого получаем 25 Гб / 8 / 4 * 2 ~ 2 Гб.

А в сумме одна сессия Qwen 3 Coder Next - 42 Гб - уже помещается в память ноутбука. Не каждого, да.
Правда эта память медленная, да и CPU не очень подходит для перемножения матриц. Но это уже совсем другая история)

А еще можно квантовать и значения в KV кэше, что в теории уменьшит размер памяти в 2 или 4 раза.
И шарить память между разными видеокарточками на одном сервере по шине NVLink - это называется tensor parallelism.
Если у одной NVidia H100 80 Гб, то у сервера с 8 видеокартами - уже 640 Гб.
Плюс часть данных можно выгружать в ОЗУ и на SSD.

#ai

В продолжение предыдущего поста - цифры по памяти получаются большие, и это на достаточно скромной модели.
У условного ChatGPT будет в 50 раз больше, или 40 х 50 = 2 Тб.
Как оно работает?

Как работают коммерческие LLM мы не знаем, открытых данных по коммерческим провайдерам: OpenAI, Anthropic, Google - нет.
Поэтому далее будет много предположений.

В качестве крупного провайдера LLM возьмем ChatGPT.
Пусть у него 1 млн карточек NVidia https://www.tomsguide.com/ai/sam-altmans-trillion-dollar-ai-vision-starts-with-100-million-gpus-heres-what-that-means-for-the-future-of-chatgpt-and-you.
Пусть это NVidia H100, т.е. получаем 80 х 10^6 Гб памяти.
Ремарка: снова хочется сказать - вот куда вся память делась!)
Размер памяти для хранения модели как уже говорилось пусть будет 2 Тб = 2000 Гб.
Пусть одна модель шарится на 10 серверов: в один (8 х 80 = 640 Гб) такая не влезет, а если шарить слишком на много серверов - вырастает latency.
На 10 серверов получаем 6400 Гб памяти, 6400 - 2000 = 4400 Гб на KV кэш.
Размер сессии у нас был 2 Гб х 50 = 100 Гб, но это для кодинга.
Исходя из данные тут https://www.index.dev/blog/chatgpt-statistics 50% можно сессий можно считать рабочими (кодинг, проекты), 50% - вопросы и ответы.
Вторые сильно меньше по контексту, пусть будет 3 000 токенов. Среднее - 33 000 токенов.
Т.е. на сессию берем 100 / 2 = 50 Гб.
4400 / 50 ~ 100 сессий на 10 серверов.
Пусть на инференс уходит 80% карточек. Остальное оставим на обучение и тестовые стенды.
Это 800 000.
Итого, система держит 800 000 / 8 / 10 * 100 ~ 1 млн сессий.
DAU у ChatGPT порядка 100 млн https://www.incremys.com/en/resources/blog/chatgpt-statistics
По часовым поясам они распределены неравномерно, возьмем 16 активных часов.
Это 100 / 16 ~ 6 млн человек в час.
Итого - уже не хватает, учитывая что 50% сессий длинные, а аудитория растет.

И тут можно понять, почему все агенты повторно шлют историю с каждым запросом, см. https://t.me/javaKotlinDevOps/581.
Хранить в памяти сессию, не зная вернется ли пользователь, с такими нагрузками нельзя.
Соответственно, тут или сбрасывать на диск (наверное SSD) в векторизованном виде, либо хранить ID сессии и каждый раз преобразовывать заново из текста запроса.
Если используется первый вариант, а для скорости ответа это важно - то становится понятно, почему также подорожали и SSD диски)))

#ai

Хочется добить тему с MCP, точнее о проблеме с загрязнением контекста тулами из MCP.
Схемами тулов, если уж быть точным.

Есть еще одно решение - MCP Progressive Discovery.
Т.е. MCP сервер не сразу объявляет все доступные тулы, а по мере необходимости.
Как это сделать?
Объявляем meta-tool, один.
В его описании указываем все, что умеет MCP.
Как только клиент его вызывает, возвращаем ему что-то типа: "подожди немного и вызови вот такой тул".
Бросаем событие list_changed - это часть протокола MCP, позволяющая динамически менять список объявляемых тулов и оповещать об этом клиентов.
А клиент, соответственно, получив данное событие обновляет список тулов и вызывает нужный.
Будет ли работать на всех агентах - думаю нет, надо тестить. Агент должен поддерживать событие list_changed.
К слову, если объявить у MCP сервера кастомное API слушателя событий, и бросать ему туда события о том, что происходит в агенте - можно даже не ждать, пока он вызовет Meta-tool.
Ну, например, начали работать с git - логично показать соответствующие тулы.

Еще вариант - тот же meta-tool, но заменяющий собой несколько атомарных тулов.
Например, за все операции с git.
Я тут вижу много проблем: теряем Single Responsibility, схемы становятся формальными (объявляем что-то типа response: object), валидация типов будет происходить в коде в рантайме.
Но в каких-то случаях может пригодится. Можно его переформулировать как упрощение API MCP сервера с целью уменьшения размер схем.

#ai #ai_agents #mcp #ai_agent_context_management

Я уже писал, что протокол общения между агентами пока не стандартизирован в моем понимании, хотя лидирующеэий стандарт - A2A - вроде как есть. Даже в Spring AI поддерживается.

Но кажется у него появился сильный конкурент)

#ai #ai_standards

Есть такая проблема у AI агентов - постоянные подтверждения действий.

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

Почему не помогают существующие настройки?
У большинства агентов есть permission mode.
По умолчанию он спрашивает разрешения на все, кроме чтения.
Можно включить edit mode и всегда разрешить редактирование файлов.
Ок, но вызовы shell при этом будут требовать подтверждения.
Также можно ограничить список тулов как в основном агенте, так и в субагентах.
Но тот же shell тул нужен.

И на самом деле как раз с ним и проблема.
Да, для вызовов тулов включая shell есть allow и block листы.
Где-то они работают по совпадению префиксов, где-то по регулярке.
Первый вариант совсем грустный, т.к.

echo file1.txt file2.txt file3.txt | xargs rm

Но и регуляркой сложно закрыть цепочку из нескольких команд, выстроенных в конвейер.
А LLM такие команды любит.
А разрешение bash(*) - это по сути разрешение всего.
Да, можно разрешить вообще все - yolo permission mode (Cline, Qwen) или bypassPermissions (Claude).
Но тут есть риски - если код из Git можно восстановить, то файлы с рабочей машины - не всегда.

Что делать?

Решение номер раз - виртуалка\Docker. И далее подключаемся по ssh или Remote Development в IDEA (тоже ssh).
Некоторые агенты встроили эту фичу в виде sandbox, но похожий результат достигается самостоятельно - Docker и ssh.
Вроде проблема решена, но есть нюанс.
Иногда в самом деле нужно подтверждать действия в процессе выполнения задачи, чтобы не переделывать код на финальном ревью человеком.
Это может быть этап промежуточного ревью кода моделью или исправления падающих тестов.
Или скачивание каких-то зависимостей из нестандартных репозиториев.
Или рефакторинг, требующийся для выполнения текущей задачи.

О серьезности проблемы говорит множество тикетов на эту тему. Я взял из трекера Claude:
https://github.com/anthropics/claude-code/issues/6850
https://github.com/anthropics/claude-code/issues/2719
https://github.com/anthropics/claude-code/issues/3361
https://github.com/anthropics/claude-code/issues/13340

Тут есть интересное альтернативное решение - Claude Auto Mode https://code.claude.com/docs/en/permission-modes#eliminate-prompts-with-auto-mode
То, что его придумал Claude думаю никого не удивило)

В чем суть?
Этот режим заточен под длительные сессии разработки и призван минимизировать подключение человека.
Как это делается?
Есть ML моделька, обученная как я подозреваю на данных Claude.
У нее есть список разрешений и запретов по умолчанию:

Blocked by default:
Downloading and executing code, like curl | bash
Sending sensitive data to external endpoints
Production deploys and migrations
Mass deletion on cloud storage
Granting IAM or repo permissions
Modifying shared infrastructure
Irreversibly destroying files that existed before the session
Force push, or pushing directly to main

Allowed by default:
Local file operations in your working directory
Installing dependencies declared in your lock files or manifests
Reading .env and sending credentials to their matching API
Read-only HTTP requests
Pushing to the branch you started on or one Claude created

Плюс модель читает лог текущей сессии и добавляет запреты из команд разработчика.
Если действие признано запрещенным - причина запрета возвращается в агента, и он пробует другие варианты.
Не зациклится ли он - тут зависит от силы модели.
Если какой-то запрет будет срабатывать слишком часто - 3 раза подряд или более 20 за сессию - режим временно выключается и требуется подтверждение пользователя.
После подтверждения - включается заново.

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

Итого, подход правильный, но к сожалению он доступен только в "дорогих" режимах начиная с Max.
Ну и по API тоже, это самый дорогой режим вообще говоря)
Ждем в других агентах.

P.S. И, вообще говоря, его можно обучать на данных из локальных сессий, чтобы он подстраивался под пользователя.

#ai #ai_development_problems

Прошла неделя и Auto Mode раскатили на все тарифные планы. Круто!

P.S. Интересно, что там за модель-классификатор для определения опасности команд работает. Есть подозрение - что Haiku, самая дешевая из тройки моделей Claude Haiku-Sonnet-Opus.

P.P.S. А еще одно радостное событие - аналогичная фича появилась в Qwen Code 0.16 https://github.com/QwenLM/qwen-code/releases/tag/v0.16.0

И раз уж заговорил про Qwen Code - они догоняют ведущих агентов (Claude Code и Codex) еще в нескольких моментах:
а) параллельная работа над подзадачами через worktree (там, где это возможно, конечно же)
б) Goal-driven workflow (/goal)
в) /rewind с восстановлением файлов

Причем если с /rewind отставание в 9 месяцев, Auto Mode - 2 месяца, а /goal - меньше месяца. В общем все агенты взаимно обогащаются фичами друг друга. И это хорошо!

#ai #ai_agents

Немножко про стандартизацию CLI агентов.

Сравнил слэш-команды у четверки наиболее популярных\актуальных: Claude\Codex\Gemini\Qwen.

Рабочий цикл:

/init - инициализация контекста - есть у всех
/plan - режим планирования, без выполнения - есть у всех
/goal - установка цели (evals или DoD) - 3 из 4, причем: фича появилась буквально месяц назад
//... тут идет разработка
/status, /context, /stats - просмотр информации о сессии - 4 из 4, но часто разделено на 2 команды - типа /status и /context. Как по мне - лучше слить в одну, я их путаю)
/compact (/compress) - ручное сжатие сессии - все, но терминология разделилась
/memory (/memories) - просмотр контекста проекта - 4 из 4, но Codex не смотрит на тренды)
/diff - просмотр незакоммиченных изменений - тут пока слабо, 2 из 4, но есть git и IDE
/resume - возобновление рабочей сессии - 4 из 4
/review - собственно ревью - 3 из 4, где-то есть 2 варианта - локально и на GitHub, где-то реализовано как скил с возможностью быстрого вызова
/clear (/new) - новая сессия - есть у всех

Итого - есть путаница с информацией о сессии, не везде есть /diff, дилемма /compact vs /compress. Т.е. 7 из 10 стандартизированы, по 3 наблюдаем.

Настройка оснастки (harness):

/model - выбор модели - у всех
/skills - просмотр и вызов скилов - у всех
/mcp - просмотр и включение MCP серверов - у всех
/agents - просмотр и добавление субагентов - 3 из 4, как ни странно Codex отстает, все работа с субагентами через конфиги
/hooks - просмотр и редактирование хуков - 3 из 4
/tools - список встроенных тулов - 2 из 3
/plugin(s) (/extensions) - работа с плагинами, включая установку из marketplace - 4 из 4, но терминология не выработалась. 3 разных варианта

Итого - практически стандарт, за исключением tools и терминологии plugin vs extension.

Безопасность:

/permissions - разрешения для тулов - 3 из 4

База:

/exit (/quit) - все
/theme - все
/vim - 3 из 4, для любителей Linux, но Claude его удалил, и это может стать трендом
/help - 3 из 4
/bug (/feedback) - все, Codex опять не в тренде)

Тут тоже все стандартизируется.

Удобство работы:

/copy - копировать последний ответ в буфер - все, и штука полезная, но малоизвестная. Claude даже n последних позволяет.
/btw (/side) - by the way или side вопрос - возможность что-то уточнить не открывая новое окно во время работы агента - 3 из 4
/recap - краткое резюме по сессии - 2 из 4
/statusline - настройка собственно statusline, как это принято в Linux - 3 из 4

Даже на таких мелочах и то стандартизация)

Передний край, развитие - фоновые задачи и ветвление:

/fork - создание параллельной сессии для исследования темы - 2 из 4
/rewind (/resume) - откат либо в рамках текущей сессии, либо убить форк - 3 из 4
/loop - запуск по расписанию в сессии, не путать с циклом - 2 из 4
/tasks (/bashed, /ps) - просмотр фоновых задач - 3 из 4

Общий итог - стандартизация явно вырисовывается.

#ai #ai_agents