Как накачать агентов к лету:

Пятничное)

Мы начинаем наш стрим!

Подключайтесь по ссылке: https://youtube.com/live/X71ZfXMKslo?feature=share

SKILL-аудитор префикс кэша потихоньку обновляется, и я рад что он приносит пользу! (58🌟 на GitHub это же мой самый успешный опенсорс проект! пойду делать курс "Как достичь успеха в ИТ")

Вот например Рефат законтрибьютил поддержку Vercel AI SDK и Mastra, а еще важных и свежих изменений в Claude API. В целом, считаю что само наличие такого контрибьютора обрекает проект на успех)
А я закинул полезных правок, которые подглядел у Богдана и знания про бенчмарк vllm для запуска с проверкой кэша.

Спасибо за обратную связь и звездочки!

Кстати - эфир про кэш и контекстную инженерию с Родионом и Костей, который мы анонсировали раньше, обрел свою дату - 4 июня, 16:00 мск. Но я еще напомню)

Ищу крутых ребят в команду AI платформы Битрикс24
Знаю что тут достаточно трушных инженеров, вы то мне и нужны)

Сейчас нанимаем в 2 направления:
1. AI Evals
2. Backend Python

Что такое платформа?
Это основа, на которой строятся все AI фичи компании, начиная от простых сценариев, заканчивая агентами, управляющими Б24. Наши заказчики это продуктовые и внутренние команды, которые генерируют больше 20 млн запросов в месяц (и это только llm).

Мы отвечаем за модельки, которые крутятся под капотом (для этого у нас больше 100 серверов с GPU от t4 до 8хH200), за их качество, доступность, производительность и тд. Еще у нас есть вот эти ваши лайтллмы, роутеры (недавно прикрутили vllm-sr), эвалы (они же бенчмарки), guardrails и другие интересные штуки.
Сейчас мы кросс-команда в которой есть как разработчики, так и ML, DS и *Ops инженеры.

Что за AI Evals?
Сюда смотрим инженеров, готовых развивать систему оценки качества LLM-фич и агентов.
Нужно понимать как строить такие evals-системы, что должно быть в датасетах и как его собрать, на какие метрики опираться, почему нельзя просто попросить LLM-as-a-Judge оценить ответ от 0 до 100, и само собой уметь в Python.
Большим плюсом будет опыт создания бенчмарков для определенных доменов, кейсов и тд.
Тут выдавали базу о том как тестить AI.

Что нужно на позицию Backend?
А вот сюда ищем человека, который любит production backend, инфраструктуру, API, очереди, observability, тесты, эксплуатацию и хочет строить backend именно вокруг AI-платформы.

Нужно будет строить и поддерживать сервисы, интеграции и инструменты внутри платформы, gateway, гварды, а еще фиксить vLLM, потому что мы не можем ждать пока они сами это сделают)
Ключевые слова: RabbitMQ, Redis, Docker, GitLab, ELK, Otel, observability, логи, трейсинг, 42.
Идеально если есть опыт с vLLM, Triton, Litellm, Langfuse.
Вот тут Андрей, dev из нашей команды, рассказывал о некоторых особенностях с которыми сталкиваемся и как их решаем.

Куда писать и что присылать?
Пишите мне в личку: @Ser_no

В сообщении лучше сразу прислать:
- на какую роль откликаетесь: AI Evals или Backend;
- CV / LinkedIn / GitHub;
- пару слов, в чём вы сильны;
- любые артефакты, если есть: код, схемы, демки, дашборды, отчёты, посты.

🔥 База по экономике токенов и кэшированию от AI Platform Lead из Bitrix24

Знакомьтесь, Сергей Нотевский. AI Platform Lead в Bitrix24.

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

Мы попросили Сергея поделиться материалами для тех, кто хочет оптимизировать косты на LLM в проде. Сохраняйте методичку по prefix cache метрике, которая напрямую влияет на ваши деньги.

Как говорят создатели Manus:

“KV-cache hit rate is the single most important metric for a production-stage AI agent.”

🛠 Что внутри методички (комбо из 3 статей + код):

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

Частые анти-паттерны — почему ваш кэш постоянно сбрасывается и вы платите больше.

Кэш в AI-агентах — специфика работы с памятью в автономных системах.

🍒 Вишенка на торте: готовый SKILL для агента, который делает ревью вашего проекта, находит анти-паттерны и предотвращает низкое попадание в кэш.

— Забрать комбо-материалы на GitHub

P.S. Если хотите послушать Сергея вживую — ловите его на конференциях Kode Waves (май), Conversations AI и Highload Spb (июнь).

🎁 Акция в честь старта продаж!

Прямо сейчас при покупке Инженерного трека вы получаете полный доступ к материалам курса «Разработка ИИ-агентов» в подарок.

👉 Забрать 2 курса по цене 1 и начать обучение

Как там было: лучший способ разобраться самому - научить другого?

Давненько я не участвовал в внешних(внебитриксовых) образовательных программах.
Да и честно говоря не особо встречаю такие программы и курсы, где:
- я видел бы себя в качестве преподающего,
- мне было бы что сказать
- остальная программа мне понравилась.

Ну и вот такой курс нашелся.
Буду вести блок про оптимизации ресурсов на аи-системы, кэширование, роутеры и другие платформенные вещи в AgentOps от Proglib.

Будет мясисто и интересно, как и остальная программа курса)

Все ссылочки в посте внизу!

Я спрошу: «Затраты на self-hosted llm это же только стоимость GPU, да?»

Менеджер скажет: «Пффф, Сережа, это же очевидно!
Еще затраты на ФОТ, ведь нам люди нужны чтобы как минимум инференсом заниматься!»

Промпт-инженер парирует: «Думаю мы потратим больше времени, чтобы заставить работать аи-сценарии на непроприетарных моделях…», и будет прав.

AI product engineer рассмеется в ответ: «Ха! Да вы же заплатите временем пока патчите vLLM для поддержки responses API!»

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

Пришло время для анонса следующего выступления, которое пройдет уже завтра.

В рамках Kode Waves, расскажу про переезд с MaaS на Self-hosted модели, через историю с нашими решениями, граблями и немного с велосипедами.
В программе: p99, очереди, тестовые инстансы, evals, маленькие модели, которые требуют больше инженерии, длинный контекст, который не всегда такой длинный, и люди, которым всё это потом поддерживать.

Участие бесплатное, в Калининграде, говорят будет и уютный оффлайн.

Регистрация тут.

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

Сегодня в разборе - три статьи от Сергея Нотевского про кеширование промтов, которые форвардил несколько дней назад: @sergeinotevskii622

Еще раз, статьи - золото:

- Главное понятие, с которым нужно подружиться: KV-cache hit rate, то есть как часто ответы вашей LLM достаются из кэша, а также процент вашего промта, который кешируется

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

- Ключевое правило – кэшироваться будет та часть промта, которая одинакова между запросами в LLM с точностью до символа. Как только в промт попадает что-то меняющееся, например, сегодняшняя дата с секундами, кэш отрежется, и все, что идет после, не будет закэшировано

- Промт лучше структурировать так: Tools, System, Messages. Брейкпоинты кэша ставить либо в конце System, либо в начале Messages, в зависимости от того, насколько динамичные у вас диалоги и какая часть из них одинаковая. Для Tools обязательно используйте sort_keys=True, иначе некоторые библиотеки могут случайно менять порядок тулзов, и кеширования не будет вообще. Плюс думайте про динамические списки тулзов - озможно, такая оптимизация убьет вам всю экономику и агент будет стоить в пять раз дороже

- cache_control нужно ставить ни в коем случае не в системный промпт, а на уровне API Anthropic в нужные JSON-блоки обращения в модель

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

- Если вы используете OpenRouter вместо походов напрямую, он добавляет дополнительный уровень маршрутизации между внутренними провайдерами, и ваш запрос может попасть на непрогретый сервер без кэша (Bedrock вместо Vertex), и вы получите кэш-мисс

- У антропиков можно явно выставить руками кеш-брейкпоинты, но не больше четырех. Например, парочку в секциях System и один в Messages. Тогда если у нас что-то меняется в конце System, сработает первый в System, а если ничего не будет меняться, сработает последний Messages закеширована будет большая часть промта

- У антропиков есть два варианта кэширования на пять минут и на час разной по стоимости. Первый обойдется на 25% дороже, а второй в два раза. Зато чтение из кэша обойдется в 10 раз дешевле стандартной стоимости

- Также кеш влияет на время ответа от модели. Например, на промпте в 50 000 токенов без кэша время ответа может быть 12 секунд, а с кэшом 1 секунду

- У провайдеров есть минимальный размер промта для кэширования. Например, у Haiku это 4000 символов, у других моделей порядка 1000. То есть если у вас слишком простой промт, то кэширование будет доступно лишь при определенном наполнении истории

- В том же Anthropic кэширование работает не на уровне API ключей, а на уровне Workspace, для того чтобы нам было удобно иметь много разных проектов, агентов и не плодить для них разные API ключи

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

- С точки зрения мониторинга hit rate и latency ответа не должны сильно бегать от релиза к релизу и в течение дня, когда у вас система прогрета. Посматривайте на эти графики

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

———
Уперся в лимит сообщения, на этом все!

Увидимся в новых сериях

Ну а если вдруг вам лень читать все три статьи про префикс кэш, Леша Остриков написал подробный TLDR, за что ему респект)

Кстати, Алексей в прошлом году взял золото в ERC3(такое соревнование на лучшее решение задач с помощью агентов) и делал делал подробный разбор.
Рекомендую его канал, один из тех, в которых читаю каждый пост.

Всем привет!

По не зависящим от нас причинам, вынуждены перенести наш стрим "Каждый токен на счету".

Новая дата и время проведения: 27 мая, среда, 17:00 мск.

Событие в календаре уже перенёс.

Спасибо вам за понимание!

И так бывает!
Зато у вас есть возможность еще подумать над вопросами)

"Каждый токен на счету".

Вы его ждали – и он пришёл. Анонс нового стрима!

Для большинства пользователей то, что OpenClaw или Hermes едят токены с лопаты – не проблема.

Дело в том, что использует эту обвязку вокруг агента один человек. Поэтому и разница в пять раз (хорошо если в пять!) по количеству используемых токенов – это разница между $20 и $100. Для человека с доходом в $2000 и то, и другое – приемлемая цена за удобство от использования личного ассистента.

У бизнеса, как правило, степеней свободы меньше. Так как включается эффект масштаба. И мы получаем уже выражение вида "цена" умножить на 20 сотрудников и ещё на 10 бизнес-процессов. И разница, в таком случае, получается между $4000 и $20000... Это в маленькой и скромной компании. Представьте, что творится хотя бы в среднем бизнесе?

Время представить гостей:

Сергей Нотевский. AI Platform Lead в Битрикс24. Про те крутые штуки, которые они там у себя в Битрикс24 выпускают, я ещё вам поведаю. В рамках нашей беседы Сергей расскажет о том, как настроить prefix_cache и сэкономить на этом "десятки поцентов костов" (прямая цитата из этого поста).

Родион Мостовой. Создатель CodeAlive.ai – системы организации контекста для программных проектов. Несколько лет Родион занимается тем, что оптимизирует контекст для LLM и, как следствие, токены, которые на него уходят.

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

Дата и время проведения стрима: воскресенье, 17 мая, 16:00 мск

Место проведения: мой YouTube-канал

Чтобы не пропустить – добавьте в календарь!

Круто, что материалы по кэшированию токенов нашли отклик у вас)
Спасибо всем кто зашарил пост, это лучшая поддержка какая только может быть!

А я несу ещё новостей:
Поштурмив с Костей и Родионом, мы решили сделать стрим, в котором обсудим и пощупаем разные подходы к «умному» управлению контекстом, контролю расхода токенов и другие прикладные способы не потерять как лишние средства так и мозги вашей AIшки.

Оставляйте вопросы в коментах к этому посту, а мы разберем их и постараемся ответить на стриме.
До встречи в воскресенье!

Люблю смотреть презентации новых AI-фич и AI-продуктов под особым углом.

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

Но внутри большого продукта это обычно:
права, API, лимиты, сервера, модели, стоимость, latency, обсервабилити, система качества, пачка неопределенностей и смелых решений. А еще - кто-то, кто будет разбираться когда вся эта красота решила к чертям отвалиться в проде в 7 утра перед пиком нагрузки в начале рабочего дня пользователей.

То есть кроме обзора самих новинок, для меня такая преза еще и показатель - какие куски AI-кухни конкретной компании уже стали достаточно взрослыми, чтобы доехать до обычного пользователя. Потому что одно дело - собрать прототип или приложение для себя, и совсем другое - выпустить фичу которая повлияет на миллионы пользователей.

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

Её я тоже буду смотреть под обоими углами - как пользователь и как инженер. Правда, того самого чувака который в 7 утра "тушит" аварию я знаю лично) Саша, привет!

Приходите посмотреть - будет очень много AI. Горжусь за этот релиз, и думаю что мы действительно круто продвинулись в "нанесении" пользы с помощью этих ваших LLM-ов.

П.с. если очень долго смотреть на экран то после первой части можно будет увидеть автора сидящего в кресле и рассуждающего о вечном.

Методичка по префикс кэшу

“KV-cache hit rate is the single most important metric for a production-stage AI agent.”
- Context engineering for AI Agents, Manus

Метрика которая имеет прямое влияние на деньги, которые вы тратите на AI.

Ниже - три статьи разбирающие prefix_cache с разных сторон:
- Экономика кэширования и особенности провайдеров
- Самые частые анти-паттерны
- Кэш в AI-агентах

И вишенка на торте - SKILL для ревью проекта, поиска анти-паттернов и предотвращения низкого попадания в кэш.

AI да парень

Кэш и агенты

Завершаю серию статей про prefix_cache (они же - кэшированные токены) третьей частью, про особенности кэша в ai-агентах.

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

Завтра подвезу сразу 2 полезных артефакта про кэширование префиксов, а пока у меня вопрос.

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

Но возможно "умные" люди просто молчат)

Давайте проверим.